#component library

You can check the slides for James' talk 
here
.

Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.

In this talk, I will share my experience in game development using ReactJS/CSS. We will explore how to make the most out of the component management provided by this library, along with the capabilities of CSS for creating an appealing user interface. Additionally, we will uncover how to leverage the React Three Fiber library to create games with a 3D experience.

Aren't You Tired of Repeating Yourself? Tired of repeating the same code over and over again in your React projects? In this talk, we'll discover the power of headless components, a design pattern that separates the logic from the presentation layer, allowing you to create reusable and flexible UI components.
We'll explore how headless components can simplify your development process, saving you both time and effort. We'll examine popular headless component libraries and provide tips for integrating them into your projects. Whether you're a beginner or an experienced developer, join us to discover how headless components can help you streamline your React development and create high-quality, customizable UIs.

CSS variables have become so sophisticated in recent years that they now enable us to do things that aren't possible with JavaScript. In this lightning talk, I'll explain how MUI's engineers are leveraging the power of CSS variables in our new React component library, Joy UI, to deliver components that automatically adapt their style and structure to the context in which they're rendered.

Most current UI libraries provide great user experience with a vast of components. But when it comes to heavy customization, and non-standard scenarios, especially for E-Commerce, they become hard to manage, scale or even slow down performance.
How to create a UI library that provides users the most possible freedom in customizing components, while keeping our performance and scalability to the fullest? How much accessible we can provide out of the box to our users? How much customization freedom is enough?
That's what my talk's about.

This talk is about an example approach on how to organise maintenance across multiple teams, where we talk about how we came to this plan at Jumbo and what benefits it brings to the Developer Experience while being able to continuously deliver features to our customers.
We're dealing with maintenance, ownership, adding small features, upgrading from Vue2 to Vue3 and the culture that supports this way of working.

At Jumbo Tech Campus we have a distributed model when it comes to our component library. The way we work on our shared codebase has helped is in migrating from Vue2 to Vue3 with the combined efforts of the entire frontend capacity.

What makes a component library good? In order to create a component library that people want to use you need to navigate tradeoffs between extensibility, ease of use, and design consistency. This talk will cover how to traverse these factors when building a component library in React, how to measure its success, and how to improve adoption rates.

There are many ways of authoring components in React, and doing it right might not be that easy, especially when components get more complex. In this talk, you will learn how to build future-proof React components. We will cover two different approaches to building components - Composition and Configuration, to build the same component using both approaches and explore their advantages and disadvantages.

Building a design system is not enough. Your dev team has to prefer it over one-off components and third-party libraries. Otherwise, the whole effort is a waste of time. Learn how to use static code analysis to measure if your design system wins over the internal competition and data-driven ways to improve your position.

Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.

GraphQL exposes application data as a graph which can introduce challenges if your backend isn't graph-ready (think slow JOINs as a result of nested GraphQL queries and the dreaded n+1 query problem). The Neo4j GraphQL library enables developers to build GraphQL APIs backed a native graph database using only GraphQL type definitions. In this talk we'll see how to build a GraphQL API without writing any resolvers, add custom logic, and deploy to the cloud.

In this talk, we'll cover the libraries, tooling and processes we use to roll out GraphQL to hundreds of developers at Yelp.

Let's face it React is a way of building component driven applications. So technically we are all doing component driven development. But are we. Are our components really isolated, composed and tested in isolation or are they still coupled together just a little bit!! Let's take a look at how you can really be component driven so you can build, scale and reuse React components across all your React applications.

Everyone has a pattern library or dreams about having one. We went through conversations and the codification of our visual dictionary and then we ended up with a beautiful living document.
But what happens when we need to re-use our components and they don’t fit in the design? How do we re-use our patterns in slightly different use cases?
We have all the tech to make a front end really modular, we have techniques and methodologies which enabled us avoiding the bad parts of the languages we use. Every part of the puzzle seems to be falling in the right place.
Yet, sometimes we are struggling in handling the variations of our patterns in a reliable and maintainable way. Our codebase is getting filled with exceptions and overrides and refactoring of base patterns becomes impossible.
Not a recipe for success, more of a way to frame the problem, identify some ideas we tried and re-discuss the way we approach componentisation.

So you built a component library. Congrats! I am sure it is awesome but did you put the same effort into its documentation? Component libraries tend to have giant APIs, dozens of components, hundreds of props and thousands of permutations. That is a lot of information to unpack.
We could make the documentation very long or... super interactive. We combined component previews, API documentation, props editing and code editing into a single seamless experience. You can quickly explore various settings of each component while watching the code write itself.
This talk will show you how to leverage common tools and concepts such as Prettier, babel and AST transformations to build the documentation that can literally work for you.

In this talk I’m going to convince you that paid UI components will solve all your problems, and that you should immediately give me all of your money. Maybe. Or perhaps I’ll draw on my experience working both on free and open source tools (jQuery, jQuery UI, NativeScript), as well as paid tools (Kendo UI, KendoReact), and discuss which type of tool makes sense depending on your team and needs. In any case the talk will go fast because lightning is in the title.

If your company is anything like the ones I’ve worked for, you have apps with seven different button designs, three different datepickers, and a bizarre collection of dropdowns that may or may not be accessible. A growing trend to deal with this inconsistency is to build a custom design system or component library. Essentially, you build The One Way™ to create a datepicker for your organization, and ask that the rest of your company to conform to your new system. But building a component library comes with a lot of challenges, like, which frameworks or libraries should you use (if any)? How do you make sure your components are accessible? And how to you distribute your components so your whole company can use them? In this lightning talk you’ll learn how to build a component library fast building on top of a library like Kendo UI. You’ll learn tips
&
tricks on how to get up and running, how to customize components, and how to distribute components throughout your organization.