Components, Patterns and sh*t it’s Hard to Deal with

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at React Advanced 2021, check out the latest edition of this React Conference.

FAQ

The speaker is Marco Chedero, an engineering manager at PhotoBox.

The main topic of Marco Chedero's talk was about modular architectures, components, and design patterns in web development.

Marco Chedero referenced the movie "Lost in Translation" by Sofia Coppola.

Habitat 67 is a building in Montreal, Canada.

In 2013, React was released, which revolutionized the approach to building web components.

Some of the challenges include managing code to use patterns without making them too rigid, reusing patterns in different use cases, and ensuring that exceptions to design patterns are meaningful and necessary.

Marco Chedero discussed several solutions including class name injection, ad hoc modifiers, specialized patterns, parent component constraints, sibling component spacing, and open components with well-defined APIs.

Marco Chedero emphasized the importance of engineers communicating effectively with designers to create a shared understanding and dictionary for design patterns, and to ensure that exceptions are meaningful and necessary.

Technologies and methods mentioned include BEM-like approaches, class name injection, ad hoc modifiers, specialized patterns, and open components with well-defined APIs.

Marco Chedero prefers vertical teams that handle end-to-end responsibilities from database to frontend, as this simplifies the flow, process, and maintainability of the UI.

Marco Cedaro
Marco Cedaro
29 min
22 Oct, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
This Talk discusses modular architectures, patterns, and components in software development. It explores the concept of creating components and pattern libraries, as well as the challenges and benefits they present. The Talk also delves into managing code for flexible pattern usage and the responsibility of modules. It addresses issues such as class name injection, specialized patterns, and modifying components. Additionally, it emphasizes the importance of communication and collaboration with designers, testing UI complexity, and organizational responsibility for UI.

1. Introduction to Modular Architectures

Short description:

Hi everyone, today I will be discussing modular architectures, specifically focusing on components, patterns, and the challenges they present.

Hi, everyone. It's a bit awkward because, again, you might hear from everyone on this stage and other stage that we haven't been in front of people for a couple of years now. It's freaking daunting to be, again, on a stage and in front of people. But none of the other speakers asked to speak after Max. That adds up to the stress, to be honest. But luckily, I have a topic that is completely different from his, so that kind of put me in a different ballpark, completely.

So this talk comes from a long way, as well. Max was 2018. Mine is a little further back. You'll see it in a minute. And it all started when I wanted to talk about modular architectures. So that building, if you're asking me, since last time I was at a conference, someone asked and I didn't know the answer. It's called Habitat 67 and is in Montreal. Anyway, I wanted to talk about modular architecture and I was trying to wrap my head around what to say about it, because modular architecture has been something that I've seen recurring in a lot of different jobs I had in the last few years and no one actually got it right. Well, not a company that I was in anyway. It is difficult. And then, while I was talking about the problem that I was trying to look at, I ended up looking at components and classes. So that was where my mind went. Calling a talk classes and components is not really fashionable nowadays, though. So it's like I need a marketing spin on it. Components and modifier, but that sounds very 2012 as an approach. Did every one of you work with a BEM-like approach in your career at some point? Writing CSS and components that way? Yeah, so it's fairly old. It's not something you would do nowadays, maybe. I mean, you might be, but it's not super appealing.

And anyway, the problem wasn't much the components and the modifiers. It was more about the overrides. Like, when it doesn't work. Like when we have to do something to undo what we abstracted, or generalized, anyway. And again, trying to get my head around it, I ended up talking about components, patterns, and shit is hard to deal with. Because this is really what I want to talk about.

2. Exploring Patterns and Components

Short description:

I used to be a webmaster before becoming an engineering manager. Today, I want to discuss patterns, components, and the challenges they present. Let me begin by mentioning the movie Lost in Translation, which explores a non-romantic relationship between Bill Murray and Scarlett Johansson in Japan. This movie, like my talk, raises different opinions and leaves room for interpretation. I won't provide answers, but rather raise problems and share my experiences with framing and solving them.

So my name is Marco Chedero. I used to be a webmaster. I used to be a webmaster way before it was cool. And I'm now an engineering manager in PhotoBox. We are hiring, by the way. If you're interested.

You might notice that I'm an engineering manager. So I'm kind of disconnected a bit from day-to-day of front-end development nowadays. But I still have an opinion, and here I am.

So patterns, components, and shit it's hard to deal with or I came up with a good use of quotes from Lost in Translation. Who of you have seen the movie Lost in Translation from Sofia Coppola? Okay. A few. Did you like it? Yeah? Okay, a few. Okay. So Lost in Translation, in case you don't know it, is a movie while Bill Murray and Scarlett Johansson are getting into a non-romantic relationship while they are on a trip to Japan. It's a middle-aged man shooting a commercial for a whiskey. She's a young woman married to a, no sorry. She's a girlfriend of a photographer that is doing a shooting in Japan, and they have a lot of free time, and a lot of jet lag. And they start this non-romantic relationship talking about his middle-age crisis and her way of figuring out what to do with her life in her early 20s. So it's a little bit conversational and about finding yourself and your way, your path and whatnot. So this movie brings a lot of different range of opinions from people. I do relate in particular with this one. Sorry for the guys and the girls who loved it. And I do think that my talk, to a point, might leave you with the same feeling. I hope not, but it might. It might. And that's because, as a disclaimer, I'm not going to give you any answers in this talk. I'm going to raise problems to you. I'm going to walk you through some of the ways I frame those problems, and some of the ways those solutions kind of worked or didn't. And then I'm going to leave.

3. Lost In Translation and the Rise of Components

Short description:

Lost In Translation starts from a comment from Alla Kolmatova about meaning getting lost in translation. She talked about design patterns and creating a visual pattern library for companies. In 2013, an article changed the way we looked at design, revolutionizing the concept of breaking down a design into small units of code and visual elements called atoms. This was the first time we heard about the mindset of creating components, which was a significant shift from the traditional PHP-based approach.

And that's it. So that's that. So, everything, no really, Lost In Translation starts from a comment from Alla Kolmatova a while back. So she said that meaning is complex and often gets lost in translation. Everybody has their own mental model of things. She was talking about design patterns specifically.

So she was talking about creating a visual pattern library for companies, not specifically code components. But I think it kind of represents pretty much how I feel about components in general. It does, so this was an amazing talk she gave a few years back. I think it was 2015 or something. But yeah, like, if you can look it up on YouTube, it should be there somewhere.

So again, as I was saying before, this talk comes from a long way. So 2013. 2013, I just moved to the UK, I'm working in Shazam. We are building stuff with a very unfashionable technologies. So we're doing moustache, some in-house small JavaScript framework when required JS was still a thing. And we use CSS with more CSS really. So we're doing very, again, nowadays unfashionable stuff. And then at some point in 2013, this article came out. Some of you might remember it. And kind of changed the way we looked at design. From that moment on, it revolutionized completely the way people was thinking about how to break down a design and create small units of code and of visual elements called atoms that you would bring together and create molecules and then organisms and templates and pages and put all that together.

And that was the first time some of us from time developers heard about that mindset of creating components. And it was freaking out with technologies that we had at the time. Because we came from a world where PHP would render the old page and you had some CSS sparkled on it, and that was about it. And JQuery on top with the interaction. But that was all you had. There wasn't the concept of small units. It could break down includes and things like that. But it was more thought in the sense of making sense in the server for the PHP blocks to work rather than building up a layout.

4. Web Components and Pattern Libraries

Short description:

Web components were announced a few years earlier but under-delivered. In 2011, they promised to isolate logic and encapsulate UI, but the concept of pattern libraries and componentization had been around for a while. The web became more mature, requiring more abstraction. The goal is to have portable, scalable UI development with less specialization.

So, this changed the way we looked at things. A few years earlier, though, web components were announced. We can say by now that they under delivered a bit. To use an alphamism.

In 2011, when they were announced, they were a promise of a change for web development. We thought we could isolate completely our logic, we could encapsulate our UI, and we could deliver things in complete isolation from the rest of the page. And we were looking forward for it. But we go back a little bit further. Because in the design side of web development, it's not uncommon to have heard about pattern libraries and breaking down the design, even before 2010. So this is a long way coming for componentization for web. Again, most of us experienced it after the article in 2013. But again, it's a long way coming. And that's because, in my opinion, the web became more and more mature and we need more and more abstraction. It's what happened with print. Until we got the movable characters, it was not a mainstream media. And that kind of transition came for web as well. We want portable things. We want 200 developers working on a UI. We don't want a small team of a few, which works pretty well. Don't get me wrong. All the technologies we are creating nowadays, though, are to solve organizational problems, if you think about it. Everything is in the direction that you need less specialization and more people being able to rotate across different technologies. Sorry. I'm digressing. Anyway.

Pattern libraries, what I mean by it, because, again, it's difficult. We get lost in translation. We have different amount of models. I want to specify what I mean. So by pattern libraries, I'm not doing a distinction in this talk about design and code.

5. Managing Code for Flexible Pattern Usage

Short description:

I'm talking about a set of components that build your UI. However you frame them. It is something that you have in a tool. It is something that you have in Figma. 2013. React got out, and this is the true revolution of components. This is when we actually started doing components properly and in an easier way. Let's deep dive in the issue that I want to talk about. The issue that I want to target is how do we manage our code to use patterns without making them too rigid for the day-to-day evolution of them, the day-to-day activities.

I'm talking about a set of components that build your UI. However you frame them. It is something that you have in a tool. It is something that you have in Figma. Wherever you have them. If you have them. But ultimately, it's what you use to declare your UI. Somewhat. Pulling them together. If you code them every single time that there's a new Figma thing and you don't present it in your code, that's fine. It's still a pattern library to me for the purpose of this talk. Sorry. Yes. Apologies.

2013. React got out, and this is the true revolution of components. This is when we actually started doing components properly and in an easier way. This technology changed the approach completely. It took a bit before it became widely used as it is nowadays, of course. It is this moment to me, and that's why I'm in this conference, really, that changed the way we started building things. And, again, of course, then we have other technologies that came out and followed that pattern and announced it. Don't get me wrong. I'm not saying that React is the only solution to it, but this is the first that I remember that actually did that mind shift. So, that is kind of the back story. Sorry. How much time did it take me to go through the back story? Quite a bit.

Let's deep dive in the issue that I want to talk about. So, as Ala was saying in that talk, when you actually try to apply that model approach in your day-to-day, it isn't really that simple. And I have this image in my mind all the time, like when you feel like a kid trying to smash a square into a circle, that's exactly what I'm trying to understand how to not do. So, the issue that I want to target is how do we manage our code to use patterns without making them too rigid for the day-to-day evolution of them, the day-to-day activities.

6. Modularity and Module Responsibility

Short description:

This talk is about modularity and the responsibility of modules. The examples are not specific to React but can be applied in a broader scope. The code shown in the slides is from my previous production experience.

Or how do we reuse patterns in slightly different use cases? So, this talk is not about React. It's a talk that talks about modularity, it's a talk that talks about the responsibility of modules and how you break them down, how you think about them. All my examples are not in React, and that's on purpose, because I don't want us to get lost into thinking about React specifically as more a broader scope of things. You'll see things that you might be doing in similar ways in React, you'll see things that you might be doing differently in React. But at the core, it's a problem we have in React as well. And all the code that I've shown in the slides is code that I've used in production in one of the jobs I had prior to PhotoBox.

7. Class Name Injection and Ad Hoc Modifiers

Short description:

The first example is the class name injection in React. It allows injecting a class name to the underlying children, but it has drawbacks. Custom CSS can become disconnected from the base component, leading to potential issues. Visual regression testing is not commonly used, making it difficult to catch UI changes. Additionally, the flexibility can lead to deviations from design patterns and the creation of unnecessary variants. Another technology is ad hoc modifiers.

So, the first example, the technical solution to reuse components in slightly different use cases that I've seen and I personally hate, but we'll get to it, is the class name injection. So when you have... Oh, this is a React example. So, when we have a component that disposes a class name prop that you can inject in the underlying children.

A lot of people do it. Don't get me wrong, it's my take that it's bad. It works fairly well for a lot of people. So, this thing allows you to inject a class name, apply the class name to whatever children make sense to this icon button, and you apply your CSS however you want.

There are a few problems I see with this because you have a dedicated, normally a dedicated CSS file, and then you don't know how that interacts with the base of that component. You have custom CSS that gets added to an extension that lives far away from the original base button, and if the base button changes, what happens to this? Like, how does that interact? Maybe this is used only in one place in your website, and you change the base that is used everywhere else, and you break something and you didn't even know about it. Unless you have visual regression. But who does that? I mean, a few people do. But really, in the day to day, do you use it? How many of you do visual regression approval to go live with changes in the UI? Okay, two. That's what I thought. It's expensive. Like, don't get me wrong. It's the right thing to do. It's very expensive to set up and maintain and create a proper build process around that. Like, it's... It's not easy.

On top of that, like, if you have that level of flexibility, you could create things that are not following the patterns that your designer wants. Or maybe your designer made a mistake and they created exceptions that shouldn't be there. Like, there are patterns for a reason. But why is this having different colors for over and active? Is that meaningful semantically? I don't know. It sounds like... It looks like a smudge to me in the code.

So again, it works really well, because it's the most flexible way to extend anything. But the four styles could be written in expected ways and we are creating a lot of variants that are pretty much to the whim of the moment for whoever designed them.

So, another technology is the ad hoc modifiers. I'm sure we use that.

8. Specific Classes and Specialized Patterns

Short description:

Creating specific classes by masking IDs with class names can be interesting as it keeps the exception within the dialog space. However, using IDs instead of classes can lead to shipping unnecessary CSS to the app. The file size of the CSS can increase significantly with new code, making it less scalable. Specialized patterns, on the other hand, are considered appropriate extensions of a component.

It's when you create a class that is for a very specific use. It's basically masking an ID with a class name. It's interesting, because it keeps the exception into the space of the dialog, in this case, so you still have the context of the change, so you know how the override works in relation to the parent-based component. But they are IDs. They are not classes. How many of them will you have in your website? And, again, this is all real code we add. We were shipping a lot of CSS that was completely pointless to the app, because the game intent, for example, was used only once in a very specific journey for the user, and yet the dialog is CSS, was shipped everywhere. And at the time, we were really deduping CSS. So, it is flexible. It keeps proximity between the extension and the base, but then on the other end of the scale you get that there are a lot of very specific implementation, the file size of the CSS could increase a lot with the news code, and it doesn't really scale up. How many can you add? Which brings me to the specialised patterns, which is actually what we in BAM would say are the appropriate extension of a component, so this is a specific type of dialogue.

9. Modifying Components and Parent Arrangement

Short description:

It can be used several times, it's not semantically identified to one, it's not an ID, it's a proper class, and it's what you would do as a modifier. The patterns and the pattern library gets back to the centre as in you have a few predefined flavours of that basic component that get extended, they're all in the same place and they're used widely across the website. This is not much about how do we reuse patterns. It's more like, what am I trying to solve when I create these exceptions? Because this is more interesting. So I noticed that most of these exception and patterns were related to three things in particular. The first one was the arrangement with the parent components. So I wanted to make sure that the children component that I wanted to extend somewhat was positioned in a certain way in relation to the parent.

It can be used several times, it's not semantically identified to one, it's not an ID, it's a proper class, and it's what you would do as a modifier. This is a normal modifier, it keeps everything in close touch with the original base and has a semantic value that is not an ID masked by a class name. So, it kind of works better in that way.

The patterns and the pattern library gets back to the centre as in you have a few predefined flavours of that basic component that get extended, they're all in the same place and they're used widely across the website. It could drive preemptive abstraction, because you see an exception and you say, OK, this is a new thing I'm going to introduce, and you'll never use it again, making it effectively another ID. But, again, it could drive that. It's anyway not super scalable either. You have only a finite number of those anyway. Again, if you want to translate that to a more reactive world, I wouldn't use class So when you mount them, you know immediately what you're mounting. But you might have used some of these patterns anyway at some point.

So a few things I've seen in the few years, but this was not what I wanted to do when I started writing talk. I told you I don't have any answers. I'm just showing you what we had. So I was stuck. This wasn't what I had in mind. And at this point of the talk, I realized that truly it isn't really that simple. So I went back to the issue, and I tried to redefine it. So this is not much about how do we reuse patterns. It's more like, what am I trying to solve when I create these exceptions? Because this is more interesting. Rather than looking at the technical solution to solve the problem, let's go back to the drawing board. Let's take a deep look at the problem itself.

So I noticed that most of these exception and patterns were related to three things in particular. So the first one was the arrangement with the parent components. So I wanted to make sure that the children component that I wanted to extend somewhat was positioned in a certain way in relation to the parent. And in order to achieve that, another solution could be this. So instead of touching the dialogue, I could make a dialogue that is adapting to the parent size, and the parent component is responsible for applying the constraints in size, for example. So the parent component has the responsibility of defining whatever space the dialogue is adapting to. In this case the dialogue is super generic, it doesn't have to know anything about any type of extension, and the Game Intent page is the one responsible for defining the constraints. Which to a point is really good. Again, the main problem I see with this is that you'll get with a lot of HTML that you wouldn't normally have if you weren't thinking in a component way.

10. Solving Component Spacing and Flexibility

Short description:

You know, what they called devitis in a non-React conference, this is what leads to that. So yeah, not great. The other thing that we're trying to solve is the space between components. Instead of looking at the parent positioning, it's the sibling positioning. In this case, it makes more sense to have helpers, classes defined in the pattern library, and predefined spacing. Open components is a solution that requires more attention from an engineering standpoint. It's when you define an API for your components, allowing for flexibility and avoiding the need for ad hoc solutions.

You know, what they called devitis in a non-React conference, this is what leads to that. So yeah, not great. It's a solution, but it's not great. The other thing that we're trying to solve is the space between components. So instead of looking at the parent positioning, it's the sibling positioning. And in this case to me it makes more sense to have helpers, classes that are defined in the pattern library and bring back the thinking there in the design space and have predefined spacing. Again, you might not look at the style here of the CSS specifically. It might be variables in your CSS or whatnot. But ultimately, the point is you're bringing back to the pattern library, thinking about how the distance between items should be and the wide spacing between items should be is not anymore something that you need to solve ad hoc for every single component you have is predefined.

Again, it doesn't scale a huge amount, because the flexibility is not there anymore. Like you have to predefine everything. And it's something that could like if yourself and the designer are not very attentive it could be very quickly stale and not useful anymore and you will end up adding margin and padding again in your CSS. Open components. Okay. So, this is the one I like the most, personally. I think this is the solution for most of the problems. It requires a lot of more attention from an engineering standpoint. It's basically when you define an API for your components. We do that in React all the time. Like, we use the props to do that. But ultimately, here it's done in a CSS, but ultimately it's when you say, okay, this component can take a width and a height for the icon, for example, and I'm going to pass it from outside, and that's it. There is no override. There is nothing specifically that's a prefined behavior of that component. Again, in this case, again, the icon does that. It could be a structure. There are a lot of nice ways of doing it in CSS. There are even better ways in React. Again, the responsibility of being flexible is of the component you're designing, and you need to be attentive to create an API that makes sense for it, and that is consumed by the parent applying the available API. Again, this is what a React component would look like if we did something like that. You can think about how you would do that with style components.

11. Complexity and Design Patterns

Short description:

It's a common way of doing things, bringing back control and visibility to the code. However, it can become more complex, especially when dealing with multiple prop configuration types. It's important to be strict and not open up everything immediately. Another consideration is the role of a design pattern library in defining sizes and using variables instead of fixed numbers.

It's a fairly common way of doing things. It does bring back control, and when you see your code, you know immediately what it's looking like. It's not something that is hidden away from you. There is one counter side, which is that, again, it's more complex. It's a slippery slope. I've seen components with ten different prop configuration types. At that point you start asking yourself, how do they interact with each other? It could be weird. You need to be quite strict and not open up everything immediately.

The other thing that to me is more of a semantics question is, if an icon can be whatever size, then what is the point of having a design pattern library? The design pattern library should define those sizes anyway. So, you might want to use variables anyway, not numbers across the board. But in general, I would try to bring back the thinking into how we define patterns before we start opening up our APIs.

12. Communication and Collaboration with Designers

Short description:

The more you know who you are and what you want, the less you let things upset you. This is the problem when it comes to components. We need to communicate with designers better, create a shared dictionary, and understand their needs. Don't blame the designers, question exceptions, and collaborate closely with them and stakeholders. Understand the business and user value you're delivering.

Now, does it get easier? At this point in the talk, I'm going to let the movie talk for me. Does it get easier? No. Yes. It gets easier. Oh yeah? Look at you. Thanks. The more you know who you are and what you want, the less you let things upset you. So becoming an engineering manager helped with that. The more you know who you are and what you want, the less you let things upset you. And that, I think, the next sentence is like, I just don't know what I'm supposed to be, which is what Scarlett Johansson answers to that. And I think this is the problem really when it comes to components. We have a need in our company to start communicating with designers better, to start talking the language and to get them to understand our language, creating a shared dictionary to talk about things.

We need to understand how we can understand what they want and convey what we think the meaning of our reception patterns are, because a deception per se is a smell. There are reasons to create exceptions, but every time there's an exception, you should ask yourself is this something that we really need or is it something that again, the designer maybe went on a journey that doesn't fit in the big picture that we're building. And again, don't blame the designers. They know what they're doing most of the time. And sometimes these exceptions make a lot of sense, but just question it. Talk to them. Get to understand what they're building. Get to understand the abstraction they're asking you. Don't go and abstract too early and get involved very early in the design process and give a feedback on what you see. Try to get that relationship with your designers and to work with them closely. Talk to people. Not only the designer. Talk to the stakeholders. Try to understand what you're building. Try to understand the business value and the user value that you're delivering. And remember that. You're not hopeless. That was me.

QnA

Testing UI Complexity and Snapshots

Short description:

Thank you. What is it? Oh. All right. I'm a bit long, sorry. You ran a bit over, but that's okay. We can do one question and it's over. A question from Anna. UI can get quite complex, including dynamic styling. How should we test it? In my experience, manual testing goes a long way in the UI. That's why pattern library and code helps a lot. I agree snapshots are not great. Visual detection of changes could help, but it's difficult to set up and costly to maintain. There are use cases where it makes sense, but I would be wary of introducing it for any app.

Thank you. What is it? Oh. All right. I'm a bit long, sorry. You ran a bit over, but that's okay. We can do one question and it's over. So take a seat in my lair. And I will get the list of questions. Which I should have had open. I am a well-prepared real life MC. Not.

A question from Anna. UI can get quite complex, including dynamic styling. The challenge we can face is to make sure it looks like it should. How should we test it? Snapshots are not that great. So this is not an entire talk. It's not an easy question. It is tough. And in my experience, manual testing goes a long way in the UI. I appreciate that it's not always possible and is very difficult when there is a larger state of code. That's why pattern library and code, I think, helps a lot. Because if you make changes to components and you see them on a style book or whatever, it's going to be much, much easier to look at. I agree snapshots are not great. If you rely only on snapshots, something will go wrong. Again, visual detection of changes could help. It's difficult to set up. It's costly to maintain. It's not something I would recommend for any app. There are use cases where it makes sense. There are others where I would be a little wary of introducing it.

Organizational Responsibility for UI

Short description:

It's an organizational problem to me. Who is responsible for the UI and across what apps? Talk with your engineering managers and director to simplify the flow, process, and maintainability. Vertical teams, from database to frontend, with a thin slice of responsibility, can simplify the domain to an area for your website.

Again, in general, again, it's an organizational problem to me. Who is responsible for the UI and across what apps? I would try to talk with your engineering managers and director and see if there's a way of simplifying the flow and the process and the maintainability of things. I do prefer much more vertical teams. So end to end, from database to frontend and have a thin slice of responsibility across that. That simplifies quite a bit, because your domain is then contained to an area for your website. Again, not an easy one, not knowing the context of this question. I'm happy to talk about it after, if you're around.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
Design Systems: Walking the Line Between Flexibility and Consistency
React Advanced 2021React Advanced 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
The Talk discusses the balance between flexibility and consistency in design systems. It explores the API design of the ActionList component and the customization options it offers. The use of component-based APIs and composability is emphasized for flexibility and customization. The Talk also touches on the ActionMenu component and the concept of building for people. The Q&A session covers topics such as component inclusion in design systems, API complexity, and the decision between creating a custom design system or using a component library.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.