Designing with Code in Mind

Rate this content
Bookmark

For years I've been a designer who codes and I believe that designing with code or with a coding mindset can help your team to be more productive. In this talk, I'm exploring this concept and showing my daily workflow that can probably help to bridge the gap between devs and designers.

30 min
02 Aug, 2021

AI Generated Video Summary

Welcome to Designing with Coding Minds. Having a designer who codes in your team can help work faster and bridge the gap between developers and designers. Designers who can code can improve design systems and create components for design tools. GitHub is used at Elastic for collaboration between designers and developers. At Elastic, the code is prioritized over the final design, allowing the code to go live first.

1. Introduction to Designing with Coding Minds

Short description:

Welcome to Designing with Coding Minds. My name is Elizabet Oliveira, a senior product designer at Elastic. I work for a project called Elastic UI, a design system with components for data visualizations. Give it a try, it has a wide range of features.

Now let's get started. Welcome to Designing with Coding Minds. It's really a pleasure to be here in the React Summit Remote Edition. So, my name is Elizabet Oliveira, it's a Portuguese name. I'm actually, I was born in Mozambique and my father was Portuguese and my mother is from Mozambique, so I'm kind of a mix from Portugal and Mozambique, but I grew up in Portugal, in Lisbon. Two years ago, I lived in Dublin for about four years. It was a good experience, but I couldn't handle living without sun and so I decided to go back to Portugal. And since then, I'm working for a distributed team at Elastic, I'm a senior product designer and I really enjoy working in a distributed team and most of us work remote. And what I do at Elastic, I work for a project called Elastic UI. It's a design system where we have a lot of components and the idea of this design system was born for, to provide components for another project called Kibana, but with time, people outside of Elastic started using this design system. And everyday, we see more and more people using the design system. Also, a lot of people contributing with code and it's really amazing to be part of this team and especially like this design system, we have the data in mind, so we have a lot of components that helps you a lot if you're going to work with data visualizations. So it's really, you should give it a try. Especially if you have a product with a lot of data, really, we have select boxes, color pickers, icons, buttons. There's so many things that table, data grids, a lot of things just that you can think, you can find in this design system.

2. Advantages of Designing with Code

Short description:

So this is like Kibana, Kibana is the window, let's say, the window of the Elastic Stack. It's where you can visualize your data and when you can create data visualizations and there's different apps inside Kibana. There's the maps, visualize. There's a lot of things there. I want to talk about having a designer who codes in your team is a good thing. Nowadays, a lot of companies they have design systems and actually a design system can help you a lot but is not 100% perfect. For those complex scenarios, a good thing is to sketch the idea first. Advantages of designing with code. First of all, states. And I believe with a designer who codes in your team, the teams can work faster.

So this is like Kibana, Kibana is the window, let's say, the window of the Elastic Stack. It's where you can visualize your data and when you can create data visualizations and there's different apps inside Kibana. There's the maps, visualize. There's a lot of things there.

So my work, basically, I work most of the time for the design system but then sometimes I work for Kibana and today what I want to talk is about having a designer who codes in your team is a good thing and the reason I want to talk about this is because right now I start seeing that there's a lot of teams where you have designers and developers and they only collaborate with images and I think nowadays it's a little bit sad when people just work with static images like you have a figma where you have a sketch and you work like having comments or sending the link to your figma and saying, oh, this is what you should implement. This is the state, this is what you have to change and then the developer implements that and then the designer goes there and start saying, oh, this is not well implemented and sometimes as a designer you can't sometime predict all the scenarios and then you have to go back to your figma or sketch and then you have to fix that. We design and then you have to explain again to the developer what the developer needs to change. So I think that this type of conversation sometimes a little bit difficult or this way of working, sometimes it's difficult and because of that I want to convince you that it's good thing to have the designer codes in your team and nowadays, a lot of companies they have design systems and actually a design system can help you a lot but is not 100% perfect.

And why is not 100% perfect? Because if you see a case as a very big product like Kibana, okay you can have components from the design system but sometimes you don't have yet the component ready or you have to think when you build the component you have to think how that component is going to work for multiple apps inside of Kibana. And sometimes you have to create something that is only going to live inside Kibana and is not going to live inside the design system. So you have to provide designs to the developers what they need to implement and sometimes the implementation is not that easy if you think about the design part. So I believe that having someone that has the skill set to go there and build that structure inside the product can help you a lot. And sometimes just having the design system won't work for these type of scenarios.

So what is this thing of designing with code or with code in mind? For me it's like you design with code. I mean every day at Elastic I'll go to the GitHub and I create a bunch of pull requests with things like fixes or fixing parts of the documentation, improving things, add logos and sometimes I design with code and other times I design with code in mind. And what is this thing of designing with code or with code in mind? So I believe that it works better if you have a design system. So you need to have to design with code, you really need to have the components already done. So you just jump into a project and you fix things with the design system. But sometimes you have, as I said before, complex scenarios like the one in Kibana that you don't have all the components in the design system and sometimes you need to create components that are going to live just inside that project and this component is not going to be part of the design system. So I think for those complex scenarios, a good thing is to sketch the idea first. And also, when you design with code, you don't need pixel perfect designs, you just need sometimes to, when you start designing, to say, okay, this is the colors I want to use, this is design that I want to create. It doesn't need to be pixel perfect because then you're going to do the pixel perfect, let's say, with code. So you just have the idea and then you fix that with code and you tweak that with code.

So advantages of designing with code. First of all, states. You know, when you work with things like Figma or Sketch, it's a little bit difficult to create all the states. Okay, you can have symbols and you can have with Figma components that change states. So let's say a button you can have different states, a warning button, danger button, but if you create that with code, it's easier because you just need to design a little piece, let's say the button and define, this is the colors that I want and then with code you just do the rest. And I believe with a designer who codes in your team, the teams can work faster because you don't need to ask someone to build that and then sometimes go there and say, this is not well-implemented. So, I believe that having a designer codes, the teams can work really fast.

3. Improving Maps in Kibana Project

Short description:

So this is an example of something that I helped. It's part of the maps to elastic at Kibana, inside Kibana project. I was helping to create this new part of the maps called the layer style. As a designer, I could see right away a lot of issues like some of the inputs didn't have like a space and also there were some issues with the space in between them. And I could say to the developer, maybe with this screenshot put a lot of text, red text on top and saying, oh, you need space here and arrows saying what he had to fix. And then I had to go there and see if he fixed properly. And imagine that at last we are a lot of people working together. And so what I did is I jumped into the project and I fixed myself with code. I went there and I implemented properly the components that we have from the design system because he was using already the components from the design system but he was not using properly. I went to the project and I fixed that. I put the inputs with the same size and the final result was this one. I went to the Kibana project and I created a pull request. This is actually the pull request. And the pull request, I like to explain what I'm doing. I say, okay, this is the design changes. I introduced a gap between the two forms elements. All the forms elements are now compressed. All the rows are now with full width. It was introduced a fix to the left elements when we have two in a row.

So this is an example of something that I helped. It's part of the maps to elastic at Kibana, inside Kibana project. So, I was helping to create this new part of the maps called the layer style. And I had a few meetings, I said, okay, this is what we went to build. I created the design and we also have the design system in Figma.

So, I said, okay, this is what we need to implement and we have some discussions what we wanted to do. And this was like when the developer implemented. So, as a designer, I could see right away a lot of issues like some of the inputs didn't have like a space and also there were some issues with the space in between them. As you can see, like this input, this color picker is not the same size as the other inputs. He used a different size.

And I could say to the developer, maybe with this screenshot put a lot of text, red text on top and saying, oh, you need space here and arrows saying what he had to fix. And then I had to go there and see if he fixed properly. And imagine that at last we are a lot of people working together. And so what I did is I jumped into the project and I fixed myself with code. So basically I went there and I implemented properly the components that we have from the design system because he was using already the components from the design system but he was not using properly. Like also this thing, these buttons, it was just appearing on over. He thought it was going to be better because maybe I didn't provide the specs properly. But the reason I didn't provide the specs properly is because I wanted to go there after and fix that because I can code. So this is what I did. I went to the project and I fixed that. I put the inputs with the same size and the final result was this one. I want to show you how it works. So I went to the Kibana project and I created a pull request. This is actually the pull request. And the pull request, I like to explain what I'm doing. I say, okay, this is the design changes. I introduced a gap between the two forms elements. All the forms elements are now compressed. All the rows are now with full width. It was introduced a fix to the left elements when we have two in a row.

4. Designing Components for Elastic UI in Kibana

Short description:

I explained what I changed and provided explanations to the developers. This is an example of how a designer who can code can work. I designed a new component for our design system, Elastic UI, based on the need for color picker components in Kibana. I shared the design with the Maps team and we agreed on its implementation. I created a draft in Elastic UI, which generates a preview page. This is the current state of the component.

So I explained what I changed and basically I like to provide the explanations to the developers. So probably in the future, you will know how to implement properly our components from the design system. This is just a basic example of a way you can work when you have like a designer who can code. This is like a different thing like in this one was like the developer implemented first and then I went there and I fixed it. I just gave him some guidance, maybe a few screens, probably not that pixel perfect, I didn't give maybe all the scenarios possible, and I just went there after and I fixed that.

With this one, it was a new component that I wanted to introduce in our design system. And I start noticing inside Kibana there are a lot of places we start needing color picker components. And so I had this idea because we already were using different color pickers in different parts of Kibana. So I said, okay, this is a pattern that we have to solve. So I decided to create a new component and introduce this component into our design system, the Elastic UI. So for that, I created the component. This is like a screen from the Maps app. And actually, this is not pixel perfect. I just did it like a screenshot. And again, from the screenshot, I just put on top this and what I had in mind, and I shared with the Maps team, I shared with my colleagues, I said, what do you think about these new components? We all agree. I said, okay, this is what I want to build. And when I designed this, as you can see, I just have a few screens. So I probably, if I really wanted to give this to the developer, I would need much more than these. I would have to explain everything like, oh, when you click here, this will happen. And I have to explain and maybe give much more details and much more screens explaining all the different scenarios. So, because I was going to code the design of this and this was just a reference to myself, I just designed this. And what it was going to look like, not pixel perfect inside one of the apps, and I also tried in different apps of Kibana. And after that, I decided to, okay, now I'm going to implement this with code. And we've used TypeScript, and from the, when we are like defining the types, it actually generates our documentation. So, we have to explain everything. So, for instance, oh, this is the palettes, a palettes is like an array of objects that can receive a value, title, and I explain everything. Some of them, I'm a little bit lazy, I just say, hand it, and then in the future, I'll change. And then, this is the most important part, it's actually the design itself, like the styles, and how it's going to look. And then, what I do is like I create a draft in our Elastic UI. So with a draft, it generates automatically our preview page, and then from the preview page, this is the current state of the component.

5. Benefits of Designers Who Can Code

Short description:

Having a designer who can code can bridge the gap between developers and designers, resulting in better collaboration and faster development. Teams should have a balance of different types of designers, including those who are skilled in CSS and coding. The future of design tools looks promising, with startups creating tools like models, interplay, and figma. These tools have the potential to generate React code with TypeScript and improve the PR process. Thank you for watching this talk.

So, and then I can have better discussions with developers and other teams that probably are going to use these components. And I can show them, okay, this is what I have in mind, and we can have discussions, and I just code until just the design aspect of that, probably for this component, I can maybe create everything, but probably after that, a developer from my team can fix better what I didn't do properly.

So, I believe this type of working can solve the bridge between devs and designers. As you can see, it's much better if the designer can jump into the code and solve these small details so you don't have these never-ending conversations that, oh, fix this, fix that, oh, I forgot this, and then you go back. I think it's better if you have someone that knows design and goes there and fix that or create something from scratch with design.

And in different companies, this designer has different names. At Elastic, it's a product designer. There is now UX developers. Some UI developers really have design skills. And you can call this type of person wherever you want. But don't forget that teams should have different type of designers. So don't only hire or don't only try to have one type of designer. I see a lot of companies that only just have designers that create static images and then developers. I think you should have a balance of different type of designers. Ones that are really good with CSS and they know how to code a little bit of JavaScript, React, TypeScript. And then you can have one that are more visual and you can also have then even developers inside the team. And then all of them together will make the development be much more faster. And they will work much more properly together. And we will, the teams won't have this gap between designers and developers and no more just static images.

So I believe that the future we will have this new design tools. Like nowadays, I know that there's some startups creating tools like models, interplay, figma, and I believe that this is going to be the future. And I hope so that these tools can generate a React code with TypeScript or not. And then I'm not sure how it's going to happen the PR part when, how you're going to put that in GitHub, but I believe those tools are going to fix that and think about that.

And I hope you liked to talk. If you have questions, go ahead and do it. And I just want to say thank you. Let's try to hire and let's try to have designers of code working together with developers. Let's improve our teams and that's it. So my name, once again, is Elisabeth and you can find me on Twitter. This is my website and I really want to say thank you for all of you to watch this talk.

QnA

Q&A: Handling Design System Limitations

Short description:

Go ahead and you can have questions. Thank you. From my own personal experience, it's really a pain to work with designers that don't speak any code. It's better to have someone who knows a little bit about coding. Handling cases where the design system doesn't have what you want involves discussions and creating prototypes. Having a clickable prototype is valuable for conveying ideas to the production code team. In Portugal, web designers used to do everything, including coding.

Go ahead and you can have questions. Thank you.

All right. Well, thanks a lot, Elisabeth. Great talk. From my own personal experience I know it's really a pain to work with designers that don't speak any code. That's not to say they're bad designers, but yeah, it's really a lot better if you have someone that at least knows a little bit about what you're doing and can understand how to think in components. And yeah, it looks like you really nailed that. So thanks for this information.

We're going to jump right into the questions. The first question, or not mine, the first question that we got from the Slack channel is from Rita Castro. How do you handle those cases where the design system does not have what you or the designer wants to achieve, but you are not allowed to change the design system.

Yeah, so it happens a lot in Kibana, especially because every time a different app needs something new. And sometimes just because the Maps team needs something new, we won't just create a component for our design system because it's just for one. So this component will live inside the Maps team or the Maps app. But then if you see that that component, the patterning starting to emerge in different apps from Kibana, we start thinking probably we need to create this as a component in the design system. But sometimes just to create something very specific for an app in Kibana, we just start like having meetings with the team, we come up with ideas. So this is what I have in mind. And then sometimes the team itself can do the code or I can help with the code, or I can create some kind of, we start maybe with the prototype. I can create a working prototype. Maybe the code is not ready or 100% ready to start being used inside Kibana. But at least it shows, okay, this is what we want to do. And we can already start seeing some issues that the component might have, and that's it.

Yeah. Yeah, it's a lot more valuable if you can have at least a clickable prototype and it doesn't need to be production-worthy code, but it's easy to convey your ideas to the actual production code writing team if you are able to do this a little bit with a little bit of code. So that's really valuable.

Oh, and a follow-up question, also from Rita. How did you get into coding as a designer? So, because I'm from Portugal, so in Portugal we end up like doing everything. So years ago, my role was a web designer or web developer, web designer, and at that time, a web designer was someone doing everything. So my first role was like, mostly doing like WordPress teams.

Transition from CSS to React

Short description:

I started with CSS and gradually moved into front-end roles. I learned PHP, WordPress, and web design. Then I began using jQuery and eventually delved into JavaScript. I tried both React and Angular, and found React to be more intuitive for designers.

So I was starting like buying teams and changing the CSS, and then one day I had the more complex team that I had to build, so I started building from scratch my own teams. So I had to learn a little bit of PHP, and then WordPress developers and web designers and just started like moving into front end roles.

So I ended up- You're kind of forced into it. Yeah, so I end up like being a designer and doing those like UI or more like CSS. And one day I start doing things like with jQuery. And after jQuery, I started, okay, now I know jQuery, people saying that jQuery is not good. And I said, oh, I have maybe to start learning better JavaScript. And then from JavaScript, one day I just end up in a startup and we wanted to create something. And I heard people were using React or Angular. So I, okay, let me try. I tried Angular too. And it was so complex. So I, oh, let me try React. And React for me, as a designer, I felt it was more intuitive. And I just started using. And never left.

Tips for Bringing Designers into Coding

Short description:

At Elastic, we use GitHub for almost everything, including communication and sharing design assets. Designers who want to contribute start with small tasks like fixing icons or changing CSS. GitHub allows designers to see what's going on in the code and encourages collaboration with developers. Suggestions on GitHub make it easy to provide feedback and make changes. We have our design system already implemented in React, which is different from other design teams that use Figma or Sketch. Sometimes we don't have all the components in design tools because we do a lot of things with code. This hybrid approach at Elastic fosters collaboration between design and development.

Yeah. Right. The next question. Do you have any tips, how to make it easier as being a developer to bring designers into coding? At least at Elastic, I think one of the things we use GitHub for almost everything. So we communicate inside GitHub. So if you, and everything is almost open source, so anyone can see what we're doing. So even the design, when we're trying to fix something, I just put there the Figma link, or I put the screenshot. And sometimes you really want to help. So you start seeing the value of GitHub. And as a designer, you want to create your pull requests and to be a contributor. So I see a lot of designers at Elastic that really want to be a contributor, and they start with small things like fixing an icon or just changing one line of CSS. So maybe for those things that want to make designers to code, maybe if they start using GitHub, probably they will start talking in GitHub and then the designer easily can fix one line of the code there.

Yeah, it's because they see what's going on in the code because they have to communicate to the developers in code or in the code environment, GitHub in your case, then they see what's going on and might be more inclined to say, hey, this looks like I can do this. Yes, even like nowadays on GitHub, you have the suggestions. So you can, when you are reviewing the code, just maybe imagine that someone is using an Xcode instead of a color variable. And you say, hey, you can use this Xcode, this, you should use this primary that is the right variable. So maybe you can suggest that on GitHub or you can start, okay, let me pull this to my computer and let me try to change in VS Code and then do a pull request. Yeah, that's really powerful. We have time for one more question and then we're gonna go to the next speaker.

Do you use any tools to extract your design system components straight into React components? And can you recommend that? Sorry? Can you repeat the question? Yes. Do you use any tools to extract your design system components straight into React components? Actually we have these, our design system already implemented in React. And actually it's really funny because most of the design teams, they have a more advanced version in Figma or Sketch and Elastic is different. We have all the components online already in React. And sometimes we don't have all the components in design in Figma or in Sketch. Okay. Because we wind up doing a lot of things with code. And everything is live. So sometimes something is already merged and we didn't have a Sketch or Figma. That's nice. So that says to me that a lot of the people are just like you are kind of a hybrid between design and development at Elastic.

Submitting Code Before Design

Short description:

Even without the final design, I submitted a pull request with my version of the color palette picker. I prioritize finishing the code first before adding the design to Figma. This approach allows the code to go live first. It's a unique way of working that may not be familiar to everyone.

Yes. Even like one thing that I showed at the top, that color palette picker. As you've seen, I didn't have the final design. So I did the pull request with my final version, let's say, and then I have to go to Figma and include the design of the color palette picker. But I'm trying to finish first the code, and once he's merged, I can put it on Figma. So it will be first in live.

All right. That's, never heard of doing it that way, but sounds like a good way to do it. Well. Documented how you want it to work.

All right, Elizabeth, I'm going to ask you to go to your Zoom room. So there's a few more questions. So people will be asking them in your Zoom room. So thanks for joining us. Okay, thanks.

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

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
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.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
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 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
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.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
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.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.