React is a wonderful tool to write reusable components but there is no clear definition on how a good API for theming and customization should look like. There are too many approaches when it comes to styling, and choosing one of those is a crucial decision, specially for vendor component libraries like http://react-toolbox.com/.
In this talk we will go through some of the most important styling libraries, analyzing what should they cover from the point of view of a library of components, and using React Toolbox as study case. We will explore how customization and theming can be modeled for UI Kit projects with different tools. Finally, we will see a simple technique that allows one to write components that are agnostic from styling, without committing to an specific tool. This makes possible to switch between styling strategies over time and experiment with them while keeping the same component implementation.
MobX or Redux? Mutable or Immutable? Why not do both? Lets discover together MobX-State-Tree, an ongoing experiment to create an opinionated state management library that mixes mutable and immutable, OOP and functional programming, Redux and MobX
I will be talking about how to achieve Shared Element Transition with React Native for both iOS and Android.
Will explain the advantages of having a smooth continuous experience.
And since React Native doesn’t support true shared elements, I will explain how we can achieve this with a clever trick of smoke and mirror.
Everything starts with a good idea, but it takes a lot of work to make it shine. And when you do it, and people start using it, you feel the need to take it to the next level. And the next one, and so on, maintaining at the same time what it’s working in production.
During this talk, we will talk about the experience, lessons learnt and good (and bad) ideas of designing a reusable components library with React, that led us to redefine the entire UI development process and front-end architecture @ MuleSoft.
In this talk, we're going to explore the evolution of making a SPA with React. We're going to start with React's built-in setState, how it is complicated to maintain at scale, especially when it comes to sharing state and fetching data.
External state management apps like Redux and MobX can definitely help with this problem, especially when the data is fetched from a REST endpoint.
We're going to spend most of the time on the main point: Now that we're using GraphQL to take care of data management, is an external state management library even needed? Can Apollo coexist with Redux or MobX? What about server-side rendering and Next.js? What are the pros and cons of each combination?
We'll find out what's the best way to approach this in 2017.
React took the web development community by storm with its great success. Now there are also several "React replacement" libraries, which keep API compatibility but promise to be "better" in several ways (generally speed and code size), and some of them have been used in high-profile projects instead of the "original" React. And, last but not least, Facebook itself is rewriting the React internals, making the fiber-based version 16 a de-facto "API-compatible reimplementation". In this talk we'll see why these different implementation exist, how they differ from each other, and which one you should pick for your next project.
Storybook is a tool for developing ui components in isolation. And it's also for documentation and testing. I'd like to give you an overview of the stack that makes up storybook. But also I want to talk about what it's like maintaining a project like this. How did we go from 0 maintainers to 20+ and what were the lessons learned?