GraphQL Galaxy

GraphQL Galaxy 2022

Your GraphQL Groove

Phil Pluckthun

Remix Conf Europe

Remix Conf Europe 2022

Remix Flat Routes – An Evolution in Routing

Hi, I'm Michael Parter. You may know me online as Kiliman, which is short for Kilimanjaro. I've been a big fan of volcanoes for a long time. I'm excited to be speaking to you today at RemixConf Europe. My presentation will be on Remix Flat Routes, Evolution, and Routing. First I'll start by giving a brief introduction on the current routing convention as we know it today. Here's a typical routing structure. It consists of a pathless layout for public pages like the About page, a user section with its own layout which has a list view, a user detail view, as well as an edit page. Remix uses folders to determine the parent layout. It is expected that the parent layout will include an outlet to render its children. In this example, there is no user ID folder because we want the edit page to use the same user's layout as the other routes. Since the edit page is not nested, we use the dot or flat layout instead of a nested layout. When you create a nested layout, Remix requires you to create a folder for its children plus a file for the layout itself. Unfortunately, one of the drawbacks of this convention is that the folder in the layout file ends up separated in your editor since folders are typically displayed first. This can be annoying, especially on large applications with many routes. As you know, Next.js recently introduced their own take on nested layouts. Let's compare their convention with Remix. Here is the same routing structure as the previous example. Next uses parentheses for pathless layouts similar to Remix's double underscore prefix. The one thing you'll notice is that Next requires a folder for every segment of the route. The leaf route is a file named page. If a route segment adds a layout, you create a layout file. With Next, layouts and pages are separate things, whereas Remix doesn't differentiate. Again, looking back at our user edit route, Next looks for the closest layout, which is user slash layout. Another major difference with Remix is that Remix uses named exports for things like meta, links, headers, error boundary, et cetera, and Next uses separate files for each. This can result in a large number of files depending on your app's needs. It led one person on Twitter to tweet this screenshot. Granted, this is an extreme example. One of the benefits of a folder for each route, though, is that Next does let you co-locate supporting files in the route folder, things like CSS, components, images, et cetera. This is one of the main things Remix devs have been asking for. We'll discuss how Remix FlatRoutes supports this shortly. Now that we have that out of the way, let's discuss the new Remix FlatRoutes convention. It's currently a separate MPM package, but will be included in a future version of Remix as core functionality. So what are the goals of the Remix FlatRoutes? Make it easier to see the route your app is designed. Just pop open the routes folder and they're all right there. Since the file system typically sorts folders first, when you have dozens of routes, it's hard to see which folders have layouts and which don't today. Now all related routes are sorted together. Allow co-location of support files with routes. You'll see how you can keep your styles, components, and other supporting files with your routes. Remix refactored and redesigned friction. While code editors are pretty good at fixing up imports when you move files around and Remix does have the tilde import alias, it's just generally easier to refactor code base that doesn't have a bunch of nested folders. Remix will no longer require this. Additionally, when redesigning the user interface, it's simpler to adjust the names of the files rather than creating and deleting folders and moving routes around to change the way they nest. And finally, helps apps migrate to Remix. Existing apps typically don't have a nested routes folder structure like today's conventions. Moving to Remix is arduous because you have to deal with all of the imports. Also as we saw with Next's new nested layouts, flat routes make it easier to migrate from other frameworks to Remix. So Remix flat routes was first introduced as a gist by Ryan Florence back on April 7th of this year. He posted a link on the Remix disk board and I just happened to see it and I was intrigued because I too was looking to simplify my routing structure. Less than two weeks later, I made the first commit implementing the flat route spec. The trickiest part was trying to figure out how to determine the parent layout when there were no folders. Simply a dot separated file name. We'll discuss how that was implemented in a little while. An interesting point is that it wasn't until a month later that Next.js posted the first layouts RFC describing their new nested layouts convention, which is now available as an experimental feature in Next.js 13. As I mentioned before, Remix flat routes is currently implemented as a separate package. To add it to your app, simply npm install dash D Remix flat routes. Since routes are determined at build time, this is a dev dependency and it's not needed at runtime. One of the things about Remix is that although it's opinionated, it does have some escape hatches that let you add your own customizations. In this case, it's the routes configuration where you can add your own routes in addition to the default convention. Since Remix assumes the files in the routes folder use the default convention, you'll need to tell Remix to ignore all files in the routes folder. Finally call the flat routes function to scan the folder using the new flat routes convention. In the future, you'll be able to specify which convention you want to use directly through the Remix config file. Remix flat routes changes some of the file naming conventions that we're used to. For example, for pathless layouts, use a single underscore instead of a double underscore prefix. The params prefix remains the same, the dollar sign, but I'll show you how we can change that later. Instead of using folders for routes, the file name includes the entire route. So use the dot instead of slash to separate URL segments. And finally, to handle scenarios like our user edit route, the underscore suffix specifies the segment is not a layout because it has no outlet. I'll demonstrate this later. Remix flat route supports two configurations, flat files and flat folders. Flat files will typically be used for simpler apps as everything's in the file name and there are no folders. Here is the same example we used before, but using the flat files convention. Notice that there are no folders. The entire URL structure is visible at a glance without having to drill down into separate folders. We still have to identify the index route, in this case, user slash index. Notice how we named the file users dot index. Leading underscore here is simply to sort the index route before the other child routes. As I mentioned, we're using dots instead of folders to separate the paths. But without folders, how does Remix know what the parent layout is? To determine the parent layout, Remix flat routes finds the longest matching prefix and that determines the parent layout. Here we see that public prefix of public dot about matches the public TSX layout. Same with users. Remember in the previous example where we didn't want the edit route to nest under user ID? There we use dots in the file name to deal with it. But how do you deal with that when everything uses dots? Remix flat route allows you to use a trailing underscore on a parent route to specify that this is not a layout. As you can see in the edit route, the user ID should not be treated as a parent layout, hence the underscore. This ensures that users dot user ID prefix is not matched with that route and Remix will then look to the next segment for a matching layout, which is the users layout. Although flat file simplifies the routing convention considerably, it does so with some drawbacks. For example, there are no folders. We cannot co-locate supporting files with our routes. Even if we were to add rules to ignore these other files, it would require you to import them with the full path, not exactly simplifying things. Flat folders look just like flat files. The main difference is that instead of the routing being a simple file name, the folder itself is the route name. The route file, index TSX, is located inside the folder. This is similar to the next JS page file. Remix doesn't differentiate between routes and layouts. Again, layouts are simply routes without left. So index TSX or layout TSX mean the same thing. They're simply aliases and is mainly used to be more descriptive when looking at your routes. Remix supports multiple aliases for the route file. You can use either index, route, layout, or page, as well as add the underscore prefix. This helps sort route and layout files to the top of the file list when co-locating files. As we stated before, one of the main benefits of the flat folders convention is to support co-location. Here, we are co-locating support files like CSS, components, server files, images, etc. The route file will now let you import these assets as a relative import. I've been experimenting with splitting my route file into a route and a route server file. The main reason is I use Zod for validation and the package is kind of heavy. By only defining and using the Zod schema in the server file, I guarantee that Zod does not end up in the client bundle. So now that we've seen the benefits of flat routes, how do we migrate our existing app? The Remix flat routes package includes a migration tool. Simply run the command mpx migrate-flat-routes and specify the source and target folders. The folders must be different to prevent the tool from overwriting your original routes. You can specify whether you want flat files or flat folders. Here's a screenshot of the routes from the sample fakebooks app before and after migration. You can see that it lets you quickly see how your routes are structured without having to expand the folders. One way to verify that the migration went smoothly is to run the mpx remix routes command on the original routes as well as the migrated routes. Since remix-flat-routes creates the same route configuration that was generated by the default convention, the routes should be identical both in hierarchy and paths. The only differences are the file names and maybe some sorting. Over the past six months, as people have tried out remix-flat-routes, they've offered suggestions for improvements and other enhancements beyond the original specification written by Ryan. I've already started the PR process for getting remix-flat-routes into the core framework. Whether these enhancements end up in the core is still to be determined. And at the very least, I will continue to support these as add-ons that you'll be able to include in your configuration. One of the pain points of the remix routing convention, both the current and flat routes, is that the use of the dollar sign can be problematic when working with files in the shell. Since most shells treat the dollar sign as a variable prefix, this forces you to escape the file name when using commands. Considering this is RemixConf Europe, I suggest using the euro. Or if you have a typical US keyboard, perhaps the caret. Some developers want to be able to mount the remix app on a path other than the route. Perhaps they are adding remix to an existing website. Here you can configure remix to use a different path, such as my-remix-app. This will update the route path and you won't have to add a separate folder in the routes folder. Jacob Ebi, a Remix team member, recently created a sample app that had routes processed by different backend technologies, which is quite mind-blowing. He had routes from node, Cloudflare workers, as well as service workers, plus a common set of layouts. He used RemixFlatRoutes, but in order to support his needs, he had to manually combine the routes into a single namespace to ensure the parent routes were correctly defined. In RemixConfig, you can now not only specify a single path to your routes folder, but pass it an array of paths. FlatRoutes will build up the route structure across multiple route folders and merge them into a single namespace automatically, so you don't need to do that manually. And as you can see from the MPX remix routes output, that the routes were correctly generated. So in conclusion, I've been a Remix supporter since day one, when it was a paid product. It was well worth it and has definitely improved the way I build web apps today. I can't believe it was almost a year ago today that Michael Jackson first announced Remix version 1 to the world, making it available as open source. In that short time, there have been two Remix conferences, one back in May that I was fortunate enough to attend, where I was able to meet in person for the first time people like Michael, Ryan, and Ken, and many others that I've only known on Twitter or Discord. As well as this conference here today, where I'm grateful to be able to give a presentation and talk about something I've built and I'm very passionate about. And now with the recent news that Shopify has acquired Remix, we can all rest easy that this amazing framework will continue to prosper. I can't even begin to imagine the wild ride that Michael and Ryan have been on these past 12 months, and I'm excited to see what the next 12 months will bring. Thank you for taking the time to watch my presentation.


Michael Carter

TechLead Conference

TechLead Conference 2023

What Engineering Leaders Should Know About DevRel (But Were Too Busy to Ask)

Hello everyone at Tech Lead Conference. It's a great pleasure to be here and share a couple of things I know or have picked up in my career about DevRel. The first thing I'm going to share is a little story or a thought exercise. Basically we have two people, Sally and Ben. One is a developer advocate, the other one is an engineering manager. And it's your job to identify who is who. So Sally's job is to make developers' lives better. She loves to make their lives easier and developers more productive. She really finds joy in helping others do their best work. She works in a really dynamic environment where none of the two days of hers are really the same. So maybe on Monday she's speaking to a number of platform and infrastructure engineers on an individual basis, getting feedback from them, learning about their issues, helping them out if she can. On Tuesday she's supposed to be making a presentation that she's already late for, for a group of stakeholders, for a large group of people. And yeah, she just gets dragged into firefighting instead. She basically pushes back what she was supposed to do on Wednesday, so writing a blog post for the company. So that's obviously pushed back. And on Friday, she doesn't know where the week has gone and there is no chance she'll get the chance to learn about the new APIs that Amazon AWS have just released or announced. So yeah, that's Sally. What do you think she is? Developer advocate or engineer manager? I'll help you slightly because I'll tell you what Ben does. So Ben is a developer advocate. So yeah, if you thought that Sally was a developer advocate, obviously because I lured you that way. If you knew where I was going, good for you. I am that good as building suspense. Anyway, I wrote that way on purpose just to give you a little bit of a think that our jobs developer advocate here, tech leads, managers over there might actually be very similar and they are. That's all this talk is about. So yeah, speaking of jobs, I work as a developer advocate at CircleCI. My name is Zan or Zan, however you want to pronounce it, based in London. And yeah, I landed into developer relations proper doing it for pay basically about six ish years ago after finding my own startup, being a developer in an enterprise, being a developer at another startup and just kind of picking up new skills as I went. So when I had my startup, I was doing like a lot of product development, I was doing a lot of stakeholder management as you do, all the marketing, all the everything really because small startups. Anyway, when I was working at a corporation, we were going through this kind of digital transformation, which is a great time to experiment with, with kind of new things because these organizations tend to have quite a lot of capability to let you experiment. So yeah, I discovered there was a distinct lack in skills from graduates coming in, in our kind of graduate program. So I started this bootcamp program for them where they got to learn in hands-on sessions, hands-on workshops about things like Git, command line masteries like Bash and POSIX stuff, test-driven development, et cetera. Also recruited a bunch of others, other senior engineers in the company to kind of come and help out. And I started doing also blogging and public speaking at meetups, conferences in Europe and the UK. And a couple of years later, when I was working at a startup in the developer tool space, we had an opening for developer advocates or developer evangelists, they took it and it was a very, very easy transition. I also discovered one thing that engineers who knew me as an engineer from before, they interacted with me in a completely different way. They saw me as one of their peers, whereas engineers, engineering leaders who came in after I had moved into developer relations, they didn't quite see me as a peer and I had to kind of prove myself much more to them. And that's part of the reason why I'm giving this talk to you today, to kind of give you this idea of why and how you should trust your DevRel teams, they're your peers and yeah, how you can best collaborate with them. So with DevRel, as with everything, it's all about the people you have in the audience. What is your company's audience? Who is your company addressing? Could it be that your company is addressing developers? In my case, I work for CircleCI, we're a CI CD platform. Our customers, our users are all developers from platform engineers to infrastructure engineers to developer engineers to development teams. They're all developers, they're all technical. And it's very obvious to see that obviously people like me bringing feedback, bringing insights from the developer community back to the company, they tend to be very often listened to. And that's how DevRel actually got started in these kinds of companies. Then you have different types of companies that are like developer adjacent or developer plus, where they might have an aspect like an API or SDK that they provide to their customers that are not necessarily developers, but developers can use it to integrate with their tools, their products and whatnot to extend their functionality. And that's the remit of the developer relations team. So it's like much smaller slice of the whole cake. Last group of companies, probably the biggest of them all, by the way, are companies that don't really work with external developers because they have just internal teams and they don't really sell developer products. They don't have an API that they kind of see as a product, but they can still have like hundreds if not thousands of developers on their own, but they need to be up-skilled. They need to be kept up to date with the latest technologies. And that's where developer relations comes in. Just kind of like making sure that everyone is on the same page and everyone is able to contribute at their best capability. That's kind of where we are with audience, but we can also look at DevRel from where we are within the company. So we can sit in many different departments from marketing, product engineering, less so sales, just because incentives are a bit different with sales and they're kind of targets to sell versus our targets to kind of engage your developer communities in a kind of more authentic manner. Me, myself, I work in marketing, so I'm going to start with this. This is actually one of our booths at one of our events. What we do is we build brand, we build awareness. We stand on booths, we talk to folks coming to hear about us, learning what kind of tools they use, et cetera. I also give talks, I also give workshops, sit on podcasts, write blog posts, write tutorials, et cetera. So a lot of stuff that's geared around user acquisition, user engagement, bringing feedback from the communities back to our teams, from our marketing team, for example, hey, there's this new technology we need to write about, there's this new way of thinking we need to kind of adopt, or even the whole organization really. And we're also kind of this kind of bouncing ground for ideas on the marketing team. Someone can just go and say, hey, I have this idea, do you think this would work? And say, yes, you could do even better if you word it slightly differently, if you're going to address it better, you're going to resonate with your audience better, that kind of stuff we can do because we're engineering stuff on the marketing team, so we're kind of closer together with them. Product, it's pretty obvious. So you want to kind of make sure that what gets to the users is the best fit for the actual users. So we help with rapid ideation and getting feedback back, whether that's kind of prototyping ourselves, whether that's kind of going to the actual users, kind of demoing things, and kind of getting that feedback to immediately get acted on, that kind of stuff, through user research, through just kind of like interviews, etc. That could be product management. Again, lots of docs, lots of content, probably going to be written. And that's kind of the most common thread here, which is like content. And by content, I don't mean just written. It could be videos, it could be talks, it could be podcasts, it could be many ways of doing content. And then we have engineering. So obviously, there's going to be some development involved, there might be some development involved, like you might have an API, someone needs to maintain it, someone needs to write the docs for it, someone needs to run the open source GitHub community that we have, control the contributors, that kind of stuff happen within engineering. There's also recruitment. So kind of obviously, you want someone to talk to the audiences at various events, etc. And act as this kind of liaison. And that's obviously what DevRel people sometimes do, in some cases, not too often, not too many times. But anyway, we've kind of established that DevRel is a lot of things to a lot of different companies, a lot of different people. Techniques change, approaches change, kind of tactics, strategies, they change. But the main objective is the same. We're kind of there to liaise between developer communities, present the company to the developer communities, present developer communities to the company. And yeah, we work on a very hectic schedule. No two days are the same. We need to prioritize ruthlessly, we need to deal with a bunch of stakeholders. And yeah, a bunch of that actually sounds like tech leadership, to be honest. To go back to my story originally, DevRel is many things, but so is engineering and especially engineering leadership. You're working in this kind of weird schedule. People are much more important than pure tech output. And yeah, we're two sides of the same coin, you could say. That's the only gif I had, by the way. Let's look at examples. In this part of the talk, I'm going to just talk about a few areas where you could collaborate with DevRel, where you could get the most value out of us. And for us also, vice versa, where you could provide most value to the DevRel team. So yeah, let's get technical, because trust me, we are technical. We might not all be engineers. I have an engineering background personally. A lot of dev advocates do have an engineering background, but a lot of us don't. And that's completely fine, because our job is essentially to be able to have a technical conversation with people, but not necessarily we don't need to output code on a daily basis. So yeah, we are technical. I can have a conversation about any technology that you want. I can also help you distill it down to a slightly less technical audience or a slightly more technical audience or a different audience. Anyway, that's what we're really good at. And yeah, you could also say it's bridging things. So bridging gaps between areas. For example, you're in engineering, I'm in marketing. You want to know how things are. You want to change something on the website that you saw. I can connect you to the right person. You want to have someone write a blog post about a technology, maybe for hiring. I can connect to the right person, or I can help you write it. That's completely fine. That's like the gaps bridging we do. Also obviously the community bridging gap. So you want to hear what people are really saying about your product. You want to hear what they're talking about it on the streets or I mean, conference hallways or meetup rooms or whatever you want to call it. We can provide that because we are out there. We can also try things out ourselves. If you have a preview version of an API that you're building or a product we're building, we would gladly have a first go at it, give you some feedback, tell you, hey, your docs are missing a couple of things here, a couple of things there. These things are wrong. These things are out of date. Because obviously if we catch them before the community does, we don't have to deal with the support aspect of it. So that's good for us as well. So yeah, it's kind of getting that feedback from the streets and from the actual people using it. And not just from the ground level, but also on the industry level, we can provide you feedback on what new trends we are seeing in the industry. That's what we do in marketing, for example. We say, oh, this is platform engineering has been a thing for the last two, three years. It's been growing steadily. Maybe we could talk about them. We could see how we're addressing this audience. And for you, maybe there's like, oh, there's new AI APIs coming out on a daily basis. Do we use them in some ways? Maybe let's poke around. Let's see. Let's do something. I'm telling you, before something gets to this kind of public knowledge level, like AI tools nowadays, there has been people writing blog posts, doing conference talks about them for like a year or two. And that's constantly a trend. And lastly, we can have you raise your team's profile. Your profile personally as an engineering leader or your team's. For example, you want to hire more people, you want to get your face out there, right? Whether it's talking at a meetup or presenting a conference talk or writing a blog post, we can help you edit it. We can help you kind of distill down the idea so it reads better. We can help you get on a podcast, for example, because we probably have some peers doing something. We might help you kind of write abstracts for conferences, for meetups, etc. So all sorts of stuff to kind of get you and your team better out there. And to be honest, if someone is doing a talk on our behalf as an organization, you're doing my job and I'm going to be thankful for it. If I need to sit through a couple of dry runs and read through a couple of abstracts, yeah, I'll gladly take that trade. Anyway, in this kind of very brief, brief, brief overview, we kind of established what DevRel really is, to me at least, and to a few different organizations. It's a lot of things. We do a bunch of stuff. Anyway, we have a bunch of focuses, but our goal essentially is to make engineers, developers successful. Exactly like engineering leadership. Successful team, more productive team. You're more successful. So that's where we are pretty much the same, in the light. And we established a couple of ways and means where you can establish collaboration. And that's all I really have time for at the moment. But I do invite you to ask me some more questions in the Q&A. I'll be lingering on in the chats for another half hour or so. So thank you very much. I hope you enjoyed it. I hope you have a lovely day. And I hope you hear some questions.


Zan Markan

React Day Berlin

React Day Berlin 2022

Supercharging Your Dev Experience With Turborepo

Bruno Paulino

Accelerate Innovation

How's everyone doing today? All right. So today I'm going to talk about Accelerate Innovation. What that is. All right. Before that, I'm going to give a little bit of background about myself. My name is Cristobal Chao. I come from New York City. And as you can tell, I have an accent. I'm from Spain. Sorry about what happened yesterday in soccer, the World Cup. Sorry, Germans. It was terrible. We should have won, but something happened, guys. Sorry about that. Anyways. So ten years ago, I went to San Francisco and I started working for a startup. It was a front-end company. I was the first engineer. And a year later, Google acquired the company. And I was the only engineer as part of this acquisition. It was a tough bet, but I had the opportunity to work for Material Design and I helped build in version 1 and version 2. After that, I worked for Google Search and Maps, evangelizing component systems. And three years ago, I moved to New York and I started my own front-end studio. So yeah. This is myself. And today, we're going to talk about innovation. So as you may know, every day there are millions and millions of ideas, right? But only very few of them are successful. You may want to ask yourself if you have an idea that if you are actually solving the right problem. And probably not. The reason being is we are all constrained by our own biased experiences and that actually takes us away from the right problem. Let me share a story. This is 1959. Henry Kramer came with this question, like, can an airplane fly power only by the pilot's body power? It was crazy, right? Like, almost a century ago, someone asked this question, like, flying, like a bike that flies, like ET, right? So he offered 100,000 pounds to whoever can cross a canal over three kilometers. So big players were there. NASA and other big companies, as well as individuals. Ten years later, no one has figured that out yet. It's crazy, right? Ten years. They were investing a lot of money into this. They were failing again and again. But the thing is, every single project was taking too long to put together a bike that flies, like months, even years. 18 years later, no one has figured that out yet. But Paul McGrady came to play with this question. How can you build a plane that could be rebuilt in hours, not months? So with this perspective, he was actually able to create a bike that flies and fix it every day a few times in a matter of hours. So he could validate his assumptions super, super quickly. In six months only, he was actually able to cross the canal over three kilometers. The story is called You Are Solving the Grown Problem. It was published by the Stanford University of Innovation. I highly recommend it. Take a look. It's a pretty cool story. But I think the most important part here is how important are quick iterations to understand the problem better and better. And now we're talking about digital products, right? So what happens with digital products? So again, Stanford University comes with this system. You probably have heard of. It's called design thinking. And it starts with empathizing with the user, defining a solution, ideating, prototyping, and testing. And the idea is you want to quickly iterate over those assumptions and learn from every single test. Every iteration is an experiment. And as you know, Albert Einstein came up with this quote. And he's a big experimental learner, right? So what happens with the product, right? We look at the life cycle of any product. It starts with paper. You can have your idea and you can draw it very quickly and put it in front of users and get some sort of validation. But probably it's not going to be that accurate, right? The higher we go, wireframes, low fidelity, high fidelity, fully functional, and product, we're going to get better feedback, right? The product is the highest level feedback. That's the real deal, right? That's when we get punched in the face, right? But how long does it take to get there, right? That's the longest, right? Building the product takes a long time, especially if you're in a big company. The larger the company, the longer it takes to get there, right? So if we look at ourselves as developers, we're building the product, right? Innovation happens before that. That is what the designers are doing, right? They are iterating, they are innovating, and we are building what they give us, right? So if we look at this and then... Sorry. But what if we change a little bit things and we reverse this paradigm where developers can start innovating at the very beginning? This is what I call the R approach as reverse approach, or you can call it React approach, or whatever. I'm looking for names, because I think this is terrible. And it comes with this idea of having a kid's mindset, right? Kids are the fastest learners in the world, and you may want to ask why, right? Kids are constantly experimenting with different things. They don't care. They break things apart. They put things together, and they keep learning. That's why I have an accent, right? I learned English when I was an adult, so I keep it. In any case, today we have component systems, right? And component systems allow us to actually have reusable components, which actually give us a lot of time to actually start experimenting, right? React components, that's the main philosophy of the React system, right? But this is a step farther than that, which started happening pretty early. There is a company called Anima, which is exploring going to the next level. And the idea is if you have your production component in a storybook, you can actually sync this to Figma and have all the properties sync from a storybook to Figma. How cool that is, right? If we look at this, in just one click from our storybook component, we can get all the different variations of our component in Figma. So instead of looking for CSS properties, we're now looking at React components, right? There is some delay here. Sorry, guys. And I think the biggest thing here is actually the ability to be able to prototype with production components. At the end of the day, this is the highest quality feedback that we can get before product. But it's actually the feeling of having a real product. Until now, it's 2022, and Figma hasn't figured out yet, right? Having an input field, that's impossible these days right now in Figma. So yeah, this is pretty cool stuff, guys. So how do we start, right? So we're going to start with simple components that we have already. HTML5 already gives us those component systems for free. I mean, they're pretty ugly, but we can start validating our ideas, right? Then we can go a little bit higher than that with Bootstrap or Material UI. Like three days ago, I had a workshop, and in less than three hours, we put together a component system in a storybook with more than seven components, and we synced that back to Figma. So we can start innovating. Anyways, guys, this is the last thing I want to say is we're entering a new phase where developers are the new creators, right? Now we can unlock these powers that we have, and instead of spending so much time building things, we can also start innovating. All right, guys. Thank you so much. It's been a great pleasure. Thank you.


Cristobal Chao

Lessons Learned From Troubleshooting a Shopping Cart Issue

I'm going to talk about today about lessons learned from troubleshooting a shopping cart issue. So most of us have used shopping carts. My name's Hussain. I'm a staff dev at Shopify. I've been doing full stack for about ten years now, React for seven. I've made every possible mistake with React. There's my Twitter there if you want to give me a follow. Chelsea fan, unfortunately. Why this talk? So today we're talking a lot about React. A lot of us use React. We code in React. But the reality is you always work with an ecosystem, every time. So whether it's the browser you're using React on, the web APIs, like you saw a lot of event listeners, you deal with customers if you take a step back. All of us deal with customers in our code. And we're always having a business domain. Like specifically me, I'm in e-commerce now. So we all deal with those. So you deal in an ecosystem, it adds complexity to your app, which in turn adds bugs to your app. And today I'm talking about one of those bugs that I had. So just a brief background about this bug. It wasn't at Shopify. It was at a startup I worked at before in 2019. It was a restaurant marketplace app built in React and Redux. Hundreds of users, millions in GMV. Not that big, like compared to Shopify, of course. We had about 50 employees. Like about 10 to 15 were in tech, developers. So there's a happy path to the app, which is pretty standard in e-commerce. You log in, add items to your cart, provide shipping info, pay, get that money, and then receive your items. Pretty standard. This is what most e-commerce sites do. So that's what we had. But then we had a very strange problem up here. One month or less, like every once a month or less, a customer would report a specific bug. And they said they received less items than what they actually ordered. So what does that mean? So the app is kind of like very different now, so I had to do a little bit of screenshot work. So you can see here five cases of pineapple, for example, is what they ordered. So a customer, for example, would say they actually got six or seven cases, not five. Very strange, very bad. So what do we do? In the startup life, we did the same thing any developer would do, check the order on the back end, make sure the numbers were correct, checked our server logs, see if there are any errors and that the numbers matched up, checked the emails that we sent to the supplier, were they the correct number. And what we saw is it turns out our numbers in the database match everything. So we said, customer, you're wrong, our data's right, too bad, you know what I mean? So you made a mistake, essentially. And that's why it's important to kind of talk about our assumptions when we have bugs. So this gives you some context into what we were thinking at the time. So in the restaurant industry in North America, we have this concept of shorts. So when you order from Amazon, you order two or three items, you're going to get those items. Nobody tells you after you order, they say, hey, too bad, I can only get you two things out of those three. In the restaurant industry, it's different. I show up with five cases of pineapple that you ordered, I only have four. So I say, hey, customer, I only had four this morning, I'll give you a credit. Or sometimes the customer sees five cases and they say, this one looks terrible, I'm not taking it, so they give it back on the spot. So this is common in the industry, the shorts and missing items is common. The other thing is, when I order from Amazon, I order two or three things at a time. I never order like 50 coffee bags, even though I want to. In this industry, people order like 20 cans of tomatoes, 50 heads of lettuce, 60 whatever. So there's a lot of opportunity for mistakes in those items. A lot of times our customers weren't tech savvy, so a lot of times the errors were not actual errors. So this is something we were used to. And the bug didn't even happen that often. It was like less than once a month and we couldn't reproduce it at all. So to us, this is the mindset we approached the problem and it was very dismissive. And that's the big reason why I think it stayed in there. So the problem is, as we grew, it kept happening with bigger customers once a week now. So we had to start investigating very, very, very seriously. So again, the back-end approach we took, this is the one we did before, we tried it again. Try the same thing, nothing's wrong. So what's going on? What's the problem now? Okay, front-end approach. Check our front-end logs, we were using Sentry at the time, still nothing. Couldn't reproduce it in different browsers and mobile devices. QA team, still couldn't find anything. Finally we looked through our recording software called Full Story. So if any of you are familiar with Full Story, it's kind of an analytics tool that allows you to record your user sessions. Very nice app. Log Rocket is another example that I love for front-end developers especially. So with this recording, I was actually able to see the bug happening in production. I saw a customer have like order six items in their shopping cart, go, and then it's all of a sudden five. So I saw it with my own eyes, no denying it now. But still couldn't reproduce. And if you can't reproduce, how do you fix it? So now we have to reproduce it. So how could this happen? So this is an example, like shopping cart, you see this a lot with the plus minus kind of buttons. So what happened was a customer was clicking plus, plus, plus, plus, plus, plus, plus, plus, and then every time we send the request to the server and, you know, and we were debouncing and things like that, but every time they pressed the button, they were sending a request to the server. So somehow this request to change the quantity somehow was just not getting to the server. Right? Somehow it wasn't. So by the time you came to the checkout page, you didn't see it. So I had a hunch at the time because I was working a lot with restaurants in person. One thing I noticed is that a lot of times restaurants, the person themselves, they put the order in their kitchen. And in the kitchen, the Wi-Fi is usually pretty bad. So I was like, maybe the request is not making it because the Wi-Fi sucks, you know, so this could be the reason. So all I did, you might be familiar with this, do some throttling, slow 3G, and I'm like, let's give it a try. I mean, we've tried everything. And what do you know? That was the problem. Right? So we were able to reproduce it now. So how do we fix it? Well, we knew it didn't make it in time to the checkout page, which is why it happened. So you see the different quantities. So what we end up doing, and this is kind of an example here, is we're using what the customer sees at the time of checkout or the time of the shopping cart as the source of truth, not the server. What the customer sees. Because that's all that mattered. So if there's a mismatch between the shopping cart and the checkout, right, like there's six of the shopping cart and then five at the checkout, we don't care about what the server says. It's what the customer saw. So we change it back. And that's what we did. Because these are two different pages. So that way the version that the customer sees is always what they get. And we never had that problem again. So just to keep this brief, the lessons learned. The source of truth is not the server. Not always the server. Sometimes it is. Start by assuming that the bug is your fault. There's a saying about it's called select is not broken, which basically means, like, you know, the database itself is not broken. You broke something. It's you that caused the problem. Come from it from that mindset. Online recordings are very helpful for front-end developers. If you can do it, make sure you block any personal information. A lot of them do out of the box, but sometimes depending on your industry, it might be more strict. And don't test your app in the best conditions. We do that a lot as developers. We're like, on my, you know, MacBook, 64 gigs of RAM and best Internet in the world, it was perfect. So what's the problem, right? So why does this matter? Wrong assumptions can and will cost you money. I personally cost the company a few thousand dollars. No big deal, right? Now at Shopify, our scale is very massive, $3.5 million worth of sales per minute on Black Friday. So I can't do that. If I do that at Shopify, it's a lot bigger of a financial responsibility. So I take these lessons as a way not to repeat them at Shopify. And I pass this knowledge down to other developers to make sure that we approach bugs and with a mindset similar to what we did after we solved it. So that's my talk. Thank you very much. And I hope you learned something. Thank you. Bye bye.


Hussien Khayoon

Your Personal Remix!

Facundo Giuliani

React Advanced

React Advanced Conference 2022

Understand Your Codebase to Innovate Faster

How to use the Power BI to make your business more secure. How to use the Power BI to make your business more secure. How to use the Power BI to make your business more secure. How to use the Power BI to make your business more secure. How to use the Power BI to make your business more secure. So that's giving you my, or perhaps Sourcegraph's perspective in terms of how we can improve developer efficiency by helping people understand your code base more effectively. So, in terms of preparing for this talk, I was thinking about, you know, I've been in sort of software development technology for some time. And I was sort of thinking about the sort of the, I suppose the big changes over the last, well, 10 years, probably more than 10 years, that have occurred and how they're relevant to software development and how we actually deliver software applications, and how we can actually accelerate that process. So there here's my list of five, your list may be different. So, you know, open source software, you know, when I started in software development, essentially, you know, the APIs, libraries you had available to you were essentially the ones that shipped with the operating system, or came with the development tool or platform you'd invested in. Now we have libraries from, obviously, front end, we're at a React conference, of course, to back end in terms of providing databases, search tools, you know, many, many libraries, and perhaps the challenges in terms of deciding what library or framework you wish to use. And of course, there have been big changes in terms of how people go about building out software applications. So we sort of gone away from sort of the kind of big bang approach of sort of the kind of waterfall type of methodologies where we, you know, we capture our requirements, you know, that which takes some time, you know, I worked for some time for a research company, we did a lot of work for large government organizations, we suspend huge sort of requirement documents that we had to either read or prepare. So we've moved to a more sort of iterative approach, we'll be sort of smaller chunks in terms of in terms of the capabilities we want to deliver. And that's great, because it allows us to essentially shrink that loop between building and delivering applications or capabilities, additional functions, and getting feedback from our stakeholders, or clients, customers. So a much more sort of iterative, fast based approach. So essentially, you know, allows us to actually correct direction much earlier in terms of the lifecycle of a particular application or solution. And of course, you know, the move to cloud where we're, you know, again, from a software perspective, you no longer have to worry about getting ahold of infrastructure or networking as sort of kind of a base level, where you can actually go out and get someone to deliver you a database service, or provide middleware on demand without having to actually worry about how to configure or deploy or manage it. And obviously, then in terms of again, that's providing additional building blocks, in terms of actually building and delivering software solutions. And, you know, I perhaps sort of actually say there's a parallel between sort of cloud computing in some sense and open source software. Again, they're kind of fundamentally about sort of providing additional building blocks to allow software developers to sort of focus on their business problems, their business functions and capabilities that actually, that way they can really add value to their customers. And the last two in terms of continuous integration delivery can very sort of align to sort of agile development. Again, the focus is in terms of testing, which you've kind of frequently delivering software, or delivering and deploying software much more rapidly, again, shrinking that loop, but also enabling us to actually test on with smaller changes, getting additional feedback more quickly. Ideally, when you do run into problems, that sort of set of changes that you perhaps have to evaluate in terms of finding the root cause is smaller. And then finally, in terms of service based architecture, so we've got sort of big change in terms of changes in terms of how we actually build software from an architectural standpoint. So from sort of client server to three tier to these sort of multi-service type of applications. And again, where the goal is to improve or increase encapsulation and decouple applications from application logic. So again, making it much easier potentially to make changes within our code, because your changes have less impact or limited impact on other services, etc. Because you're sort of sitting behind some sort of service based API. And that's relevant in terms of front end applications as well, where there's sort of a perhaps a move to sort of allow people to create sort of micro front end applications again, where we have a set of composable application components, which we can sort of stitch together very easily. So I'd say, you know, obviously, all of these changes, initiatives, obviously, have had a sort of an impact in terms of how fast, how quickly we can actually develop software. But if we actually sort of think about the software development lifecycle, it's not sort of one big loop. Many people sort of tend to think of it as essentially an outer loop and an inner loop. So the outer loop is essentially, you know, the releases, the projects, the sprints that we're actually undertaking. So it's more of a sort of a team effort in some sense. And I probably argue that in terms of the five changes we had above is, whilst they definitely actually improve that sort of development lifecycle, they're more focused on that outer loop. Certainly in terms of you think about agile development, continuous delivery. I mean, that's their sort of square in terms of trying to improve the efficiency of that outer loop. But they have benefits in terms of that inner loop. And the inner loop is really around what you're doing as an individual developer. So, you know, OK, I have to make some change to you. I have to add a new capability. I have to fix some problem that appeared within our sort of test suite. There's an incident and I have to investigate that. Or I'm trying to sort of remove some form of technical debt within an application or set of services. So that's really the focus in terms of the actual sort of individual developers when you actually get to that sort of, you know, you're actually writing the code. You're actually closer to the source of the code. And of course, what we all want to do is basically sort of ensure that, you know, we're as efficient as we can within that inner loop. You know, once we have a great understanding in terms of the task ahead of us, once we have some kind of full context, we can really sort of, you know, we understand the tech stack that perhaps dealing with at that point in time. We can be kind of very efficient, very productive. So, you know, we know exactly what we're doing. We can get away. We're in front of our ID and we can actually write our code, test it, iterate and do it in a sort of a kind of a very efficient manner. Obviously, there are challenges in terms of and I suppose the key challenges people face is essentially, you know, interruptions in terms of that, in terms of that flow where you have to sort of switch context. So, you know, most organizations have you, we have sort of planned interruptions where we have, you know, we have meetings in terms of to update people on progress. But we have interruptions in terms of people asking us questions, other members of our team asking us questions. And of course, you know, there may be things we don't understand. You know, we don't have full context. We don't have full understanding. And we have to then go away and actually try and sort of fill in the gaps with our knowledge in order to achieve the task we're looking at. And really, it's in terms of, you know, how can we actually minimize those interruptions so everybody sort of has context and sort of has that sort of kind of, you know, kind of fast flow in terms of how they're writing software. So, you know, it's one of a sort of a cartoon that one of my colleagues pointed me out. So in terms of in terms of actually how we think about how we how we write software in terms of sort of another sort of talking about that that inner flow. So, you know, obviously, when we're writing software, we have some sort of blue sky thinking, you know, we're thinking about how best to write this method, what this class is going to look like, how can it encapsulate, how can we make it make our code easier to read, easier to change, for example. And that's that's great. But the reality is often actually we spend a lot of our time actually trying to understand what before we can actually actually be productive. And obviously that might be really basic stuff like trying to understand something about the language or tech stack you're involved in. I mean, I can remember kind of fairly early on in my career, a real challenge, you know, one of probably my most stressful time I had was actually working on an options trading system. It wasn't core part of our business, but every now and then I would be shipped off to a basement in Zurich or Frankfurt, and I'd have to sit there on a Sunday trying to fix this trading system that had suffered some sort of failure. And I had to get it working by Monday. And the code itself was relatively complex, but actually the changes I had to make were very, very simple. But I could only make those very simple changes once I had a full understanding in terms of what was causing this problem. So I spent my time trying to sort of understand that code base so I could actually make a small change to actually get the system up and running. And that's essentially the reality for many of us. We live in an age of software. Essentially, everything is driven by software in some way. Therefore, there's a huge demand to actually iterate and improve our software solutions, which leads to basically there's a lot more code out there than there used to be. We have many more developers and there's additional complexity. And in terms of if you look at the studies from people like Microsoft, this one's actually from Stack Overflow. In terms of from a development perspective, people spend 75 percent of time trying to understand their code rather than actually writing the code. So, again, really what we ideally want to do is actually sort of kind of change those metrics so we can actually get up and actually write code more effectively. So how can we help people understand their code more easily? Well, this is essentially from a source code perspective, kind of essentially our goal. How can we help people get context, get understanding more quickly so they can spend more time actually writing code? So how do we do that? Well, essentially what we do is we have a universal search platform. And essentially what that allows our customers to do, our developers who are using this platform, is it allows them to actually search across all of their code. So all of their repos, kind of regardless actually from what code host in terms of they're using for source control, but their front end repos, their back end repos, the different services that comprise their application. So they can actually get a better understanding of, you know, help them answer questions essentially. So, you know, how is this service implemented? How is someone using, who else is using this particular component? Who else is using this function or API call back to the back end? How do I use it? You know, helping people actually, you know, get that sort of more complete understanding in terms of so they can actually sort of carry out their development, actually deliver actual application code. So I'm just going to dive into give some really simple examples of how we might use this platform. Now, I'm not a React developer, but if I were, and so for me, what I can do with Sourcegraph, I can actually do some very simple queries. This system here we're looking at actually has about 2 million GitHub repos indexed on it. So 2 million public GitHub and GitLab repos. I know that Formic is a React library. So I can actually just do a very, very simple query to find out where that occurs within my code base. I can actually maybe do a slightly more complex query to actually see, actually a real query in terms of see where it's imported. So which code is actually important that that library within my code. In this case, we're doing a very simple regular expression query to actually show where in that code that occurs. If you want to dig down and actually see, look about, look at specific React functions, again, very simple queries. But again, immediately give me information about my code base in terms of where I might want to go to actually find information about how someone's actually using that function. Of course, from a React perspective, this is very basic. But of course, at that point, it allows me to actually then dig into the code. I can actually now start to look at the other sort of symbols that are defined within this code. So essentially now we're going from not just pure search, but also actually more towards sort of your actual capability you'd expect within your IDE in terms of code navigation. The key difference here is that we're actually doing providing sort of simple navigation across all of your code, not just the repos that you have on your workstation, your laptop that you're using within your IDE, but code that is perhaps lives outside of your teams or code that you don't need to touch very often. So, again, it's allowing you access to that code both in terms of search, but also in terms of code navigation. And in terms of React, we actually use React within Sourcegraph in terms of our UI. Actually, one of the things we did about 8, 12 months ago now was actually change actually how we use React. So we were actually using class components rather than function components. So, again, in this case, what I can actually do is search within, again, this is across all of these sort of 2 million repos, search across where we're using function components. But what we do with Sourcegraph is not just provide the search, not just provide the code navigation, but also allow us to use search to power other capabilities. So in this particular example, we were migrating from one code pattern to another. So what we can also use search to do is actually show us how we're actually tracking, how we're actually monitoring that particular migration. So a code pattern migration in this case. But it may be in terms of how we're actually adhering to best practice in terms of ensuring our code has relevant metadata, or how we're migrating from one library version to another across our code base. So what we can do, because we have all the code, all the commit history that we can search and index, we can actually start to actually create time series views on that code base. So in this particular case, we're showing how the migration from our UI in terms of from a class component to a function component. So essentially, what this is giving us is basically a view in terms of our changing code base. It allows us, if we're sort of responsible for that particular initiative, allows us to actually perhaps make decisions. Is this going as fast as we want? If it's not, why is that? What actions can we take to actually change or impact the rate of change for this particular initiative? And finally, one of the other things we can use search for is actually to help us actually automate changes across our code base, across many, many repos. So in this case, what we're doing is we have a script, essentially, and we're essentially using that script to find out which repos we need to change and then defining a set of steps to actually make those changes across all those code bases. So automating change across multiple repos and then allowing us to actually monitor how those changes are, how those changes are progressing through the relevant CI pipeline and review process. So the goal really is to allow, from a developer perspective, allow us to use a tool to help us actually allow us to focus on higher value work and perhaps more basic kind of code refactors that otherwise may not happen or may require us to actually liaise with many different teams in order to get them to sort of actually make those changes and then accept and review those changes. So kind of a quick tour of the Sourcegraph platform. So I'd just like to sort of thank you for your time. So, again, from a Sourcegraph perspective, our goal is to help improve that efficiency of that inner loop. How can we help developers understand their code, get context, essentially get into flow, enable their colleagues to answer their own questions rather than coming to sort of interrupt you to ask questions about the code base. I'd love for you to actually go to Sourcegraph.com to actually use universal search across two million plus repos. That includes many, many React repos or repos, all the Facebook repos, for example, that are public. Go and try it out. See what impact that has in terms of your own development kind of lifecycle. And I'd just like to say thank you very much for your time.


Simon Waterer

React Summit

React Summit 2022

Improving Developer Happiness with Preview.js

Hi, my name is Francois. I'm a developer happiness engineer from Sydney, Australia. You might be wondering what is a developer happiness engineer? What it means is that I'm a regular software engineer who likes to work on refactoring stuff or fixing flaky tests or making CI faster. But sometimes it's also about creating new tools to make other engineers faster. So one of those tools is called PreviewJS. And I'm going to be talking about that now. You might be familiar with this XKCD comic. I think it was drawn quite a while ago. But it's still somewhat relevant today. I'll give you a few seconds to read through it. So this, I think, was especially relevant back in the days of a lot of programmers using C++ or some other really, really slow language where you had to wait for five minutes, maybe 10 minutes, maybe even an hour for your code to recompile. It's not that relevant today for JavaScript. Or is it? It's actually not that uncommon these days to work on a large code base that uses maybe an old version of Webpack or a misconfigured version of Webpack that takes a couple of minutes to run the build. Maybe even worse, maybe you have to wait 30 seconds every single time you make a change to a file. Which is, if you think about it, when you add that up over a day, every single time you want to see the impact of the code change you made, that's quite a while just spent waiting. And not only is it waiting, but it also breaks your flow. So you're usually going to switch context, going to start doing something else and then you go back and it's just, you kind of lost track of what you were trying to do or whatever was in your mind is just kind of not there anymore. And it's really not very good for productivity or for engineering happiness. So let's take this example. This is a food delivery app that I called Hungry. And it's really just for the purpose of this presentation. So here we have a bunch of restaurants and let's say I feel like some French crepes. So I'm going to say crepes. Okay. There's a restaurant called Creperie François. And I'm going to go there and check out. Okay. So there are some really yummy things. Caramelized banana and chocolate. That sounds good. Fresh and candied orange. Okay. That sounds good. Okay. That sounds good. Okay. That too. Okay. I'm going to get everything. Maybe two of each. Cool. Great. And this is pretty much what you would expect from a delivery food app. And we're in the early days of releasing that to users. And the first piece of feedback that we get is that some users are surprised that sometimes the menu doesn't contain the items that they expected. So that's because sometimes if an item is unavailable, right now the API just removes it from the menu. So let's say this restaurant ran out of chicken. This first item, Kung Pao chicken, will actually be missing entirely. Which surprises users because they're like, well, did this restaurant remove this from the menu forever? Should I just completely boycott this restaurant because they removed my favorite item? But no, that's not the case. It's just unavailable today. And really that's our responsibility as designers of this app to make it clear. So instead we get a feature request from our product manager which says now we should still show unavailable menu items but just make it clear that they're not available. So you know how here we have this counter. Instead of this counter, we'll just say unavailable today, right? This should be a lot less confusing for users. Of course, the first way that we can implement this is by just running the app locally. So we're going to go to our terminal, run Yarn dev and wait a little bit. Okay, so it's running at local host. Cool. I do need to wait a little bit for this to spin up. I'm actually not entirely sure why. But there's something in here that takes quite a while. This is exactly what I meant by spending the time that you spend waiting. Like I might just go on Twitter and completely forget about this and go back here and just maybe have to wait again because I need to reload the page or something. Okay, cool. So that's our app. It's running. Now I need to find a restaurant that has a menu item that is not currently available. So I'm going to go through and try to find one. But wait, I said earlier that the API actually does not return menu items that are not available. So that's not going to work. All of them are by definition available because they're returned by the API. So I have a couple of ways to approach this. One is if I'm myself an engineer who works on the API, then I might change the API to return unavailable items. Although I have to be careful not to return them to versions of the app that don't support that yet. Or if I don't know anything about the API, I'm going to have to mock it out. So I'm going to go into my code base and find the restaurant page. And I'm going to go into that. So that's using this restaurant details page state, which is a MobX state. And really, at the end of the day, all it does is fetch. Okay, so it's fetching that, it's getting the data, it's a restaurant details response. Cool, at least this is well typed. And okay, that returns a menu item, and menu item has unavailable, which is an optional Boolean. Okay, cool. So I'm going to hack this up and say that menu zero dot unavailable equals true. And I'm going to go back to here. And so this first one, because number zero should be unavailable. But of course, we haven't implemented this, right now it still shows the counter. And now, I do know that this component is called restaurant menu item. So I'm going to go in here and say, okay, so here, instead of the counter, we want to say that if unavailable, then we show unavailable instead. So maybe the unavailable, unavailable. Cool. Nice. Cool, done. That's it. Now, of course, I need to remember to remove this, because if I don't remove this, it's going to break the experience for users. But other than that, we're done. So luckily, this is a pretty nice good base to work with. Thank you, Next.js. And yeah, we're pretty much done. So running the app locally is a lot of times the right solution, right? It's super straightforward. It doesn't require any additional setup. The only thing is that mocking data can be hard, depending on what is the specific use case that you're working with. And iteration speed can be slow. Again, only if you're working on a really complex code base or something that is not very well configured. But that's more common than you would think. Option two, we could use Storybook. In case you're not familiar with Storybook already, it's pretty much a gallery app for all of your UI components. So it's called Storybook, because you define stories for your components. Each story is a specific version of your components. So in our case, for example, we have the unavailable story, and we have the available story. So let me show you what that means. I'm going to go in here and run your Storybook. And this can take a while, depending on how many components you have. Okay, this in our case is very fast. Cool. And you can see, okay, we have this counter story, we have the no-match story, the restaurant header story, restaurant list, and so on and so on. So what we're interested in here is restaurant menu item, where we have two different stories, default and picked. So you can see that when it's picked, there is already a counter created. And I can go back in here, and let me show you how that's implemented. So we have this file next to restaurant menu item, which is the restaurant menu item.stories. And it has a little bit of boilerplate for Storybook. And then each story is this. So we have args that we define for story. So here we have two stories, default and picked. And default and picked are here. So you can see the difference is with the args that we pass, which are pretty much the props. So in our case, we want to create a new story called unavailable with a menu item that is of course unavailable. Oops, forgot a comma. Available, true. That's pretty good. And now it should appear. Okay, perfect. We have it here. But of course, we haven't, I reverted the change already. So let's do that again. Just simulating the experience from scratch. Menu item.unavailable, unavailable. Okay, perfect. And it updated pretty quickly, which is great. And let me revert that again, because we're going to do this again yet another way. Cool. The nice thing with Storybook is that it encourages good design, not just from a UX design perspective, but also from a software design perspective. So because you want stories for each of your components, you need to think about what components you want in the first place and how you want them to be designed in terms of the props that it takes, et cetera. And the way that Storybook structures stories means that you are pushed in the direction of creating dumb components that are kind of agnostic of the state, so they're not capable to Redux or anything like that. And usually that's a pretty good thing because it means that your components are really easy to test, really easy to reuse as well across code bases. So lots of good things there. It also acts as documentation, which again, is super useful. So if you want to say, tell your UX designer, hey, I have this component that is currently in this particular implementation, you can check it out at this URL. That's really super useful and reconciling that versus the box that your designer is working with. It can be a little bit slow to spin up in that it depends on how many components you have and really is something that the Storybook team is working on improving anyway. So it's not really something I would worry about too much. It does require a little bit of boilerplate. So we saw that you really can only look at components that have stories defined for them. So first you need to define the stories. If you find a component and you're wondering what it looks like and there's no story for it, you're going to have to write a story first. Cool. Is there an option three? You know how when you write markdown in your ID, let's say in VS Code, you can actually see a preview of it. So let me show you. Let's create a readme and say hello world. I'm on a max. I'm going to press command K and V, I think. Yep. And this is going to say this is instantly updated with a nice preview. I can see this is pretty cool. Cool. So what if we had something like that, but for React components? And I kept looking for that, but I never could quite find the right solution. There were a couple of contenders, but the problem is that they only work with components that don't take any props or that are super, super simple. So I decided to build it. And it's called Preview.js. It was actually earlier called React Preview because it was for React components, but then I realized that it could also work with other frameworks like Vue and Solid. So I renamed it to Preview.js and also in the process kind of reworked pretty much all of it. So Preview.js works with React, Vue 2, Vue 3, and Solid. And it's available on VS Code and IntelliJ. So let's look at what Preview.js looks like. Let's go back to VS Code. We have our restaurant menu item here, which I reverted back to the previous state. And I'm going to here have this button, open restaurant menu item in Preview.js. So I'm going to click on that. And oh, proof. That's pretty cool. Okay. So I can see a preview of that. And I, again, did not have to write any code for this. This is just out of the box. Basically what it did is it looked at the props of this. It's so, oh, okay. This specific, first, this is a React component. Therefore, I can show this thing. But also it sees, okay, that takes menu item counts on update. And it can actually look at the type of menu item and kind of generate a valid value for it. Well, at least as much as it can guess. So here, let's make it a little bit more realistic. So let's say brownies. And let's use cute kitten pictures. Although we're not going to eat the kitten. So yep, this is really just for illustration. And now this is a little bit more realistic. Now we want to implement the unavailable state. So what I'm going to do is provide an example value. Okay. And now I should be able to see what it looks like. So do unavailable. Oh, cool. That actually updates live. That's pretty cool. And I'm going to make it prettier then given I have instant feedback. That's pretty cool. Okay. A bit of padding. Maybe rounded corners. Yep. Maybe a drop shadow. Drop shadow. Yep. Oh, cool. Maybe a border as well. Border to border. Red. Oops. Sorry, typos. Lots of typos. Okay. That's what you get for recording a presentation at 11 p.m. Okay. Yep. One more time. Okay. Cool. I keep pressing save when I actually don't even need to save because privilege doesn't require you to save. Okay. So that's pretty cool. Okay. Unavailable right now. Okay. Okay. How does it look when I make it wider? Okay. Cool. That's fine. Okay. Maybe just a little. Okay. Cool. Done. That's Preview.js in a gist. Now, you might wonder if you use Preview.js, should you still be using Storybook? And the answer is yes. Storybook is pretty much still a great tool for documenting your components and making sure that you have documented every variant of it. In fact, Preview.js actually supports displaying your stories. If I go into menu item stories, you can see that I see the same Preview link for each of the stories. And I can see them like that. Which is perfect. I can also, you know, look at the restaurant header. All these different things. So, if you're just exploring a codebase, I use a Storybook and you use Preview.js and you have it set up, you probably don't even need to spin up Storybook. And this will probably be a lot faster to just use that instead. Just like that. In the future version of Preview.js that I'm hoping to release in June or July, there will actually be also a feature to save your props as a new story. Although I'm probably gonna make that part of the Preview.js Pro version which is paid. Just because at the end of the day, I would like to be able to make a little bit of money from that so I can spend all of my time working on Preview.js as opposed to having to squeeze that in my free time. But that's the gist. Preview.js works really well with Storybook. You can use both. They don't compete with each other. Preview.js is only possible thanks to a couple of recent web tooling innovations. Especially one called Vite. Which is pretty much an alternative to Webpack that is significantly simpler to set up and as well significantly faster. Your developer experience with Vite is that you update a file and within literally milliseconds, it will update. That's why Preview.js is able to do preview as you type. The only reason that's possible is because it uses Vite under the hood. If you want to take one thing out of this talk, aside from use Preview.js, of course, it's use Vite. Try it out. It's easier to set up than you would think. And it might save you literally many, many hours per week. If you want to set up Preview.js with your projects, there are a couple of steps to go through. To be honest, right now, it's not the smoothest experience, unfortunately. But unless you use, you know, create React app or something super simple, in which case it should hopefully just work out of the box. But the first thing is, of course, make sure that you use an IDE that's compatible. So, either Visual Studio Code or IntelliJ slash WebStorm. If you are not sure which one to use, use Visual Studio Code because the IntelliJ version is kind of buggy, to be honest. Working on that. And then the next thing is you have to configure it to display your components properly. Because by default, what Preview.js will do is display your components in a completely empty app. Which is not exactly perfect if, for example, you need some global CSS to be there. So, the way that you do that is by configuring a wrapper component. And let me show you what that looks like in my hungry app. It's here, Preview.js wrapper.tsx. And that's pretty much all of the config that we have. That's it. That's all the config. The important thing here is this import styles globals.css. Without this, it would look super ugly. So, let me just show you what I mean. Okay. So, I have this. And I'm gonna remove that just for fun. And it's gonna be... Yep. Really broken. Because, of course, in globals.css, in this case, I have all of Tailwind set up. And I also have a wrapper that sets up a screen container. I'm just adding a little bit of margin to make it prettier. But you might, for example, need to set some React contexts. Some, you know, initialize your redux state or whatever else you need. If you use aliases, import aliases, you might also need a couple of lines of config as well. So, as I mentioned earlier, Preview.js is quite new. It just came out in January. So, if you run into any bugs, please consider reporting them on GitHub. I really appreciate that. I'm expecting after this talk maybe a couple of hundred bug reports. Hopefully not that many. Go to Preview.js.com if you want to check it out. If you're on Twitter, you can follow me and share your feedback. I really hope that Preview.js can make your daily workflow a little bit better and a little bit faster. Thank you.


François Wouts

Fast React Monorepos with High Quality DX

Juri Strumpflohner

JS Nation

JSNation 2022

Content Modeling 101

Hey, everyone, and welcome to my talk, Content Modeling 101. Now, my name is Harsha Lagraval, and I am originally from India, living in Berlin for 15 months now, and I work as a developer advocate at Contentful. And one of the fun parts I love about my job is that I get to experiment a lot with different technologies and frameworks and share this learning with the wider community. So you can find about all these experiments and crazy stuff that I do on my website, or feel free to follow me on Twitter. Also, this is my first time in Amsterdam, so if you have any recommendations, please do let me know. So today, I am going to talk about content, because in the past two years, the amount of content that we have generated has been massive. I mean, almost everyone out there has been involved in creating content in some form or the other. And last year in November itself, during the Black Friday sale, we saw a massive amount of incoming requests being made to our Contentful APIs. The GraphQL API request increased by 550%, and the content delivery API, or the CDA, increased by 73%, and that was just in one month. And so I feel as a developer, it is our duty to make sure that we are creating an amazing experience not just for our end users, but for our team as well. And that is where content modeling comes into the picture. But the question is, what is content modeling? So a content model basically gives structure, and it helps you to organize your content. Now keep in mind that not all content creators and designers have the technical expertise like us. Hence, the goal over here is to create a content model that will support the needs of the entire team, from content creators, designers, to developers. Enough of the theory. Let's try to get into action and try to model a content for an app. And this is an app that I am working on and I want to create for myself, because I've taken cooking as a hobby recently, and I want to try out to build an app where I can store all my recipes and maybe share it with everyone else. And I want to build this because I am a programmer, and I have the superpower to do that. But anyways, there are a few things that I learned while I was researching for this, and I started working on it. And in the next couple of slides, I'll be talking about that. And one of the major things that I learned was about the top-down approach, because it helped me break down my content model. And I was able to simplify the content model and make it more reusable. So I started with playing around with the JSON schema, and I created this JSON schema. So I have a content model which has a recipe, which contains the title, a description, ingredients. Now if you see, ingredients is an array, and I'm going to come back to that. And then there are instructions, and then the images. Once I had the JSON schema and I kind of had the visual representation of what I wanted to do, I simply translated it into the content model in Contentful, and you can already see all this in Contentful. Now if you see or focus on the ingredients, it says references, many. So what I went ahead and did was I created a different content type for ingredients. So if we go one layer deep, this is what the ingredient JSON schema looks like. The ingredient has a name, and it has a type. Now I am vegetarian. I don't eat meat. So for me, I need to make sure what kind of ingredients I'm adding over there. It makes it easy for me to classify as well. So the type over here is, again, another content type. And I'm sorry I'm repeating types too many times. So this is how it looks like in Contentful, again. Now I'm not going to go into the ingredient type, because it's kind of similar. But I wanted to give you a quick view of how different content types are connected with each other. So there's recipe, which is referencing to ingredients. Reference is referencing to ingredient type. And recipe is also referencing to acid. So one of the important features of content modeling is reusability. Now taking this example of the cookbook, a lot of the ingredients are used in a lot of different recipes. And adding each of these recipes, sorry, these ingredients to each of these recipes individually does not make a lot of sense. And I personally believe that developers are kind of lazy, and they always want to find the quickest and the shortest way to do stuff. So that's where reusability comes into the picture. The next is a content model does not just store content. It also embodies the decision about how you want to render the content for the end user, how your team should publish and display the content. And we refer to this constellation of issues as content governance. And you also need to think about the platform. Where and how will the users interact with your content? Is it just going to be only on the web? Are you going to go ahead and build a mobile application? Are your users going to get this information on a voice-enabled application? So that is the other feature that you need to think about. And lastly, remember, nobody gets content modeled right in OnePass. It's a continuous process. So keep on iterating over it. Get the feedback from your team, from your users, and keep making changes. And if you want to learn more about content model or contentful, hop onto our learning center. We have some amazing courses where you can learn about them in much more detail. We also have a developer portal if you want to just get started, look at the developer resources that we have. That's the correct place to go. And we are here at the booth, and we have an interesting giveaway. So come say hi at the booth, grab some swag, and maybe participate in the giveaway. That's it from my end, and thank you for joining in, and have a wonderful time.


Harshil Agrawal

TS Congress

TypeScript Congress 2022

TypeScript for Library Authors: Harnessing the Power of TypeScript for DX

Daniel Roe

React Advanced Conference 2021

The Forest for the (Abstract Syntax) Trees

Hi, my name is Matt. I work at Shopify on the Hydrogen team. Hydrogen is an opinionated React framework and SDK for building fast and dynamic Shopify-powered custom storefronts. We are currently in a private beta, but look out for a developer preview in the coming weeks. I'm actually not going to touch on the details of how Hydrogen works specifically, but you can watch this demo with Toby, the Shopify CEO, from our Unite conference earlier this year. So, like any new framework or product, the time it takes to get up and running is crucial to the developer experience. With so many competing frameworks, all with a much longer tenure, we knew this would be an important consideration for anyone choosing to adopt Hydrogen. CreateX scripts, such as CreateReactApp or CreateNextApp, are pretty standard for project bootstrapping. But still, many of these are currently limited to cloning a template directory. This is not ideal, as it doesn't provide much in the way of configurations, and every new configuration comes with a maintenance overhead of a completely new template, and likely a lot of duplicate code. The chances that any defaults within these templates will be configured exactly to your preferences is highly unlikely. You might want to add Tailwind or Style Components or Storybook, or you might install your own internal library. In these cases, you're left on your own to stitch together your final configuration for multiple examples or duplicating previous projects, all before writing a single line of actual code. We wanted to give developers a better place to start. A command line interface that is more sophisticated, extensible, and walks with developers as they build their custom commerce experience. A CLI specific to Hydrogen development that would do more than bootstrapping projects, but that you would call out to ongoing as you develop your project and capable of an infinite number of configurations without the additional overhead. Here's a high-level mental model of how this works. First, we gather information about the project either by arguments in the CLI, a configuration file, or prompts for input. Next, we parse the existing project if there is one, or start from a base Hydrogen project, and turn it into a JSON tree-like representation. This is what is referred to as an abstract syntax tree, or AST. We then apply transformation functions to move nodes of the JSON around, effectively manipulating the code based on the inputs we gathered in the first stage. And finally, we generate new code from the JSON and write that back to disk. These stages, parsing, transformation, and generation, are common to most compilers, and we are just using Babel under the hood to do most of the heavy lifting. For those not familiar, Babel is a tool that is most well known for being one of the first ways we began modifying code written using future JavaScript features to a more browser-compatible syntax. Each stage of the compiler is dealing with a different concern. We don't use loads of template files such as EJS or Handlebar templates, and we are operating only on the AST, and the transform functions are input code agnostic. This is because it uses a common code pattern known as the visitor pattern that allows for many unique and unrelated operations on the AST object. A main function will start by walking or traversing the tree, and match nodes with transformation functions. These functions only care about the specific nodes they operate on, and couldn't care less about the rest of the code outside of those points of interest. Because each operation is isolated, they behave like the component primitive in React, and we can group common operations into a shared package. This makes composing a series of common transforms trivial, and the syntax is very approachable. There are also some great tools such as astexplorer.net or the Babel Playground that can help you write and visualize AST transforms. Imagine being able to add a progressive web app support with one command. Or for example, if we wrote a transformation that added internationalization with all the appropriate error handling and fallbacks in place. At a basic level, we might import a provider and hook, provide the hook some unique configuration based on your project, and wrap the other app in that provider, passing the result of the hook as a prop. Of course, we would also install the package and all the easy things, but being able to manipulate code in this way can lead to some pretty powerful and creative opportunities. With Hydrogen, we want to be an opinionated framework when it matters most, but there are certain add-ons in your project that may not make sense for you right at the beginning. Should you decide later that the project requires it, we can provide a turnkey process to add it down the road, and with all the best defaults, out of the box. So what are we opinionated about? Well, we care about image performance, request caching, and using server-side rendering and React server components to provide non-blocking responses and eliminating client-side waterfalls. At Shopify, we are passionate about commerce, and we want to give the merchant developers on our platform the building blocks to build highly performant storefronts using Hydrogen. In that world, we're opinionated about the difficult but undifferentiated aspects of development and want to provide a developer experience that makes web development fun again. Think of this as us trying to raise the floor on the area as we can so that you can more easily raise the ceiling within the types of creative and custom commerce experiences you develop. Take React server components. Probably not something you've worked a great deal with yet, and perhaps you're not sure about when a component should be client-only, server-only, or shared, and what primitives are available in each of those. Well, using the same parsing, transforming, and generating process I outlined earlier, we can again walk with you. We can inspect for common foot guns while using React server components and either guide you to the correct usage or just change the code for you. We can provide migrations baked directly in the CLI that will automatically look at your project for breaking changes in new versions of Hydrogen and optionally just apply a migration automatically. We also audit your project for accessibility and security, conformance with web vitals, and any framework violations. We also use the CLI internally to power integration tests, generating unique configurations of Hydrogen apps on the fly that we test in headless browsers for breakages. This protects ourselves from releasing new versions with unknown issues and also has the added benefit of us dogfooding our own tools. So this has been a quick dive under the hood of how we are leveraging compilers with everything from bootstrapping to enforcing best practices to ongoing maintenance support and even internal testing. With the Hydrogen CLI, each of these interactions culminates in a powerful and fun developer experience. Thanks for watching my talk and if you have any questions or want to shoot me a message, I'm not so big on social media, but you can find me as Cardogram in most places. Okay, enjoy the rest of the conference.


Matt Seccafien

The Legendary Fountain of Truth: Componentize Your Documentation!

Hi everyone, nice to have you here. Welcome to this session about documentation in a component-driven development era. So we're going to talk about documentation as a key success of your project. I mean, nevertheless you are working on a library, a single component, a whole design system or a final interface of an application. Your documentation is the key to the success of your project because without a proper documentation, no one is going to have a single clue about how is it working and how you are supposed to use your project or use any parts of your project. So you have to keep your documentation properly associated with your code. Fact is, leaving documentation is a pain today just because if you have to duplicate your code from your code base to your documentation, you obviously lead to a desynchronization at some point of your documentation versus your code base. So you have to keep them in sync. If you want to be ready to just simply use and sustain your documentation in time, so to have your project ready to be used by anyone in the past and in the future. So we tried many things to keep things organized between your documentation and your code base. We tried things like Storybook, we tried things like Embed, ERPL in your documentation by itself. We tried many things, but the real truth is that we need a single source of truth. And this single source is your code base by itself, not your documentation, not your examples that will be outdated at some point. You need something that is definitely the single point where everything leaves and this is directly in your code base. So we do have to do something to keep the documentation in sync with the code base. And we do need something to embed your code base in your documentation. So just a reminder about the DATX's framework. This is a documentation framework that many companies are using right now. This documentation framework is oriented in four parts. All these four parts are the dedicated parts to your documentation. And all you have to do is split different elements of your documentation in the same area. So first entry is the readme's. Readme's are the entry point of your documentation. When a user is coming to your new documentation and doesn't have any clue where to start, the readme's are the correct entry point. There are something like getting started guys, this kind of stuff. Something where you can replay all the time the same path and the same steps in your development process and you will have the same result at your hand. This is the really good way to just put your hands in your project. The second part is the O2's. The O2's are more guides or recipes and they are dedicated at how you want to work with this part of the project. How can I embed my project in a React app? How can I use my library with this kind of backend and so on? So the guides presume that you have a preset and in this particular preset, there are guides, there are different recipes on how you could use your project in different aspects of the development. The third part is the FAQ's. You have all the discussions, all the histories. Why is this project of this choice, this particular use of this tool or this preset and so on. This is where all the history of the project is living and it helps to understand why did we choose this particular setup at some point. And it helps to understand how everything interacts together. Then the final parts are main pages in the Unix era or more specifically advanced documentation about a dedicated part. How this component is working, how this library is using at some point in the project. And this is a comprehensive guide of particular deep technical content. So these four parts are attached to four different areas. Readmes and O2s are the practices points. Each time you are asking, okay, I'm working on a new part of documentation and I want to add some new content in it. Which topic is it related on? If it's related to practices, then this is the right point to have a look at. So is it something like an entry point, like a getting started stuff or is it a guide dedicated to more different access in the specific area of specific parts of the development process? So readmes and O2s, this is practice. Where the facts and the main pages are more dedicated to understanding the project and the base of the project. But the readmes and the FAQs are also the learning parts where you are learning how it is working and why it is working this way. Where the O2s are more dedicated to and the main pages are more dedicated to where I want to use the project. Which part do I have to keep an eye on? Is it on the O2s? Is it on the main pages? I am looking for a deep dive technical content or I'm looking to a dedicated guide on this particular topic because this is what I am looking for at this point. So when you have this framework in mind, you are working on a well-fitted documentation for any kind of project. So I do recommend you to keep an eye on the Ataxis framework if you don't know it right now and to try to stack your documentation to it because this is something really, really useful in your everyday work. But we are now working in a component-driven development area. So in this environment, I'm working on components more than any other parts. And this component-driven development brings us a new way to develop and to sync our application because it involves faster development, a simpler maintenance, better reusability, better CDD because every part of your application is separated in small parts, in small components. And when you split your whole front-end interface in components only, then you are able to work on all parts that are isolated in your application. And you are able to just extract your content and to have it running isolated in a sandbox environment. And in this sandbox, your component could be easily maintained, tested, and documented. And this is the part that we are looking for right now. So in this Diataxis framework, with a component-driven development era, how could we mix them all to get the most of the two worlds? What is really interesting is that when you are working like that, this is really easy to extract your component from your application and to put it in a dedicated sandbox, working in it, making some tests, making some live use of this new component, and having it available to be embedded in different parts, different era of your documentation. So your documentation can now be fully exhaustive on why is it working like that, how is this component really useful, how could we really rely on this component in this particular context and so on. So in my Diataxis framework, putting some stuff dedicated to my component in the guides of the READMEs and the O2s and so on is really, really useful because it's easy now to understand, where I could put my documentation for this particular part of my application that is this component, my dropdown, my gallery view, my hero, my button. This is exactly how I want to perform my documentation because when I am looking for a new documentation on a project, what I am looking for is, okay, what are the different components available in my library, how could I use them, how could I make them all, how could I plug them all to just interact between my components, how could I use them in React, in Vue, in Vue Is Veld, in whatever you want. So this is exactly how we have to twist our mind to just put the documentation related to a component in the right parts of our overall documentation at all. So with that, we are now able to play with the docs live because we could embed our components that is properly isolated from our final application in our documentation at hand. So it's really easy now to just play in our component in a sandbox with this component in our documentation, play with it and just try it, test it, have some kind of experiment, like it at some point. But this is not, it is no matter just because you could use your component in a dedicated area that is a living documentation. So we need to mix this component in our documentation, import it in our documentation and having it lively in here. So how could we do that right now? This is the answer brought by the MDX environment. So MDX is Markdown, but a glorified Markdown. So writing your docs. Right now you are probably using Markdown to write your documentation. This is just syntactic sugar on HTML. You probably know Markdown because it's almost everywhere right now from GitHub to any CMS or documentation platform or document production platforms. So it's a really simple syntax, easy to read, easy to contribute, even if you're not technical at all, because this is just writing text with some kind of markups that is just simple characters. So it's not that complex. It's compatible with any text editor. It's really simple to use, but it's too simple to use with really complex document. I mean, with Markdown, I can't handle my component in it. So I have to do some stuff. Okay, I can embed HTML right in my Markdown, but it's not enough. I need something more advanced and I need something more useful when I want to work with it. So this is why we have now the MDX syntax, and the MDX is just JSX embedded in Markdown. Or more than that, this is Markdown converted to JSX that is now converted to HTML. So this is a step more between the Markdown and the HTML in the rendering process. This is not just linear from Markdown to HTML, but this is from Markdown to JSX to HTML. And in this environment, when I'm working on my Markdown, in fact, I'm working in a JS or more a JSX document so I can import, export any kind of document in it. I could write Markdown in it, but I could also put my document, my component in my document right now in the end. And this is now embedded in my Markdown. And this is rendered in my Markdown at the final process. So this is really useful because now we have components in Markdown directly. So under the hood, this is just the standard Markdown level with the JSX native syntax all mixed together. We could embed external components. We could embed function rendering and external function rendering. We could pass props. We could have TypeScript native support. We could have anything that we are used to with JSX, but directly in our Markdown. Because in the final steps, this is just a rendering process where I have a Markdown syntax, an MDX syntax. Then this is converted to an AST. This is a JSX AST. Then this JSX AST is converted to an HTML AST. Then this HTML AST is converted to HTML. So this is just a process of different conversion. And this is exactly what we are looking for. We now have syntax, Markdown syntax that is flexible enough to be used to embed any kind of component. So I got a simple MDX layout. I could embed any props in it, any components in it, and I could render anything that I want. That is a regular JSX syntax or a regular Markdown syntax and mix them all. So we now have different environments that are ready to embed the MDX. MDX is really simple. This is just adding a single line of configuration in your webpack config or your webapp config. So this is really easy to do. This is not a complex setup to have. But we now split this environment into two worlds. We have in one side the naked tools that are ready to embed the MDX. I could do MDX with any kind of static generator, from Gatsby to React Static to whatever you want. I just have to embed my MDX configuration in my webpack or webapp, and everything will work freely. But this is totally naked in the sense of I don't have any preset. I don't have any layout, any playgrounds, any props, more on that later. So you do have to do anything that you want by yourself. You are totally free. This is completely flexible. But this is a lot of work at first just to have something working and documentation working. But this is really, really handy if you just want to produce a Magdon with JSX syntax. On the other hand, you have documentation-oriented solutions that are embedding MDX at first and that are providing any kind of tools that you need to embed your documentation at some point with proper layouts, proper props table, proper playgrounds, and so on. This is a solution like Storybook with native support of MDX pages or WD. It comes with more constraints because this is a documentation framework. But this is really useful. What you are looking for is producing documentation and just not producing Magdon with components in them. So if you are looking for a documentation solution, I do encourage you to have a look on documentation tools oriented like Storybook, Dougsy, and so on with MDX native support in them because they are producing every way they give you anything you need to just produce your proper documentation with them. Now you have to organize your project. When you are working on a documentation that is related to components, this is common sense that embedding the documentation in the component itself rather than having a documentation that is decorated from the components. So you have to embed everything in there. This is the Backlight view. Backlight is a tool that we are working to at DeepRiot. This is a design system editor. So it's totally components-oriented. And each part of the interface of separation of concerns oriented to components. So when I have my components, I could write my code in my components. But more specifically, I could have my stories, my tests, my documentation, my design tools, everything is embedded in my component. So I have top one where I have a big readme or a big overview of my application. That is my top components, finally. And each time I want to have a documentation related to a dedicated component like my button, I just have to go in my button, open the doc folder in my component folder, that is my button folder, and in my documentation folder, I have everything related to my component, to my button, written directly in my DOM with JSC support in MaddX. And with this MDX syntax, I could import my button directly in my documentation. Let's see how. So we have JSX components. They run in isolated environment that reacting on the wrapping environment of our components. So I just want to embed everything in the same way. So how to work with them with your home playground? Fact is, MDX is too low-level. You need something more advanced to work with them. I talked about playgrounds and table props. So playgrounds are finally some kind of sandboxes I could use to directly render any kind of components directly in my documentation. So with my playground, I could write my component or embed it directly, and my playground will be ready to extract any part of it to my rendering process. I could have a single view, a single import of my components, and I could have it in the rendering view, the compile view, an EST view, whatever I want. And this playground allows me to just have one import in my MDX, and this is rendering every part of my different views of my components and what I want. Another thing is the props table. Because my component is coming with different props that allow me to customize it, I want to have them directly in my documentation to see how my component is supposed to work. So this is a kind of reflector for component properties. This is auto-build with any kind of properties that I could expose from my component. So this is up to date because all I had to do is just to put something like, give me the props table of this component, and everything is working. This is the view of the storybook props table system. This is just a single line. You just embed a single component that is a reflector of my component. And in my documentation, I have access to any part of the properties of my component at all. So this is really handy if I want to have it. Then you could code from your docs. You could import your component that you want to document. You could write your Mac down as you are used to when you are working in documentation. Then you could embed any kind of elements related to this component. Description, the playground, the props table, everything will be in the single line, aligned with my code because the documentation is not decorated for my components right now. It embeds my component in it. So finally, MDX plus component stories format plus playgrounds plus props table. Boom! This is the best world. You could just have a documentation that is totally related to your components at all. So how to migrate to MDX? You're probably already working on the documentation in the Mac form. So you don't have to add up anything. You just have to organize your documentation from the ADDX framework to your different components. So have it properly isolated, each documentation to each component at the side. Then you could pick your right tool or a naked or a documentation framework tool or a documentation platform. Then you could start to play with your components. And that's all because MDX is just paving the way. This is just the first tool of a new era. And I'm pretty sure that we will have a lot of other formats and a lot of other tools to embed our documentation and improve our components or Yanti documentation. But writing documentation outside of writing is just nonsense. We do have to embed our code in our documentation. And this is the premise of the MDX format. This is what we are looking for. You do have now to focus on advanced and integrated dev tools rather than just reinventing the wheel at some point. You just have to be focused on what you are looking for. This is exactly what we are doing with the tools we are working at DevRiot, like Backlight, of webcomponents.dev. If you have any questions, we will meet in a Q&A session just right now. For everything else, thank you very much. I'm Mads, I'm a principal developer advocate at DevRiot, where we're working on document and components-oriented solutions like webcomponents.dev or Backlight.dev. So that's our design systems-oriented IDE in your browser, directly in your browser, with anything you need in it, like documentation process with MDX, playgrounds, props, table, and so on. Have a look at them. Thank you very much.


m4dz 🥑🦄

Supercharging Developer Productivity With Advanced Code Search

All right. So, if you're on sourcegraph.com, just follow me. So, I'm Prosper Otemiwa, I work as a developer advocate at Sourcegraph. We have an agenda. So, every developer in the world spends a huge amount of time reading and writing code. In fact, if you use GitHub a lot, you discover that even when you're on your laptop, you're on GitHub, you're trying to get notifications for pull requests, comments, and every other thing you're doing with code. Right? So, if you spend more time reading and writing, then you should have the tools that allow you to search for code very easily. So, we have a tool called Sourcegraph. Sourcegraph.com. That's why I said you should open your phones. If you open your phones, go to Sourcegraph.com. I like to call it the Google of code search. So this is how it looks like. If your interface doesn't look like that, you're not on Sourcegraph, please. Just cross check. Right? So, with Sourcegraph, this is the value we offer to developers. Sourcegraph has currently indexed over 2.1 million open source repositories across GitHub and GitLab. So, right now, you can search code on Sourcegraph, and it gives you data from GitHub and GitLab. Right? And you can also set private code across several repositories. With Sourcegraph, the same way you can do local search on your local IDs, you can have precise code intelligence on Sourcegraph.com. And with Sourcegraph, there's a feature we have called batch changes. Instead of automating, instead of opening several pull requests to different repos, with batch changes, you can have a file and it can make several pull requests for you instead of you having to do that yourself. So, it's called batch changes. And then we have two features called code monitoring and code insights. But for this talk, I'm going to be talking more about the search. All right. So, like I said, Sourcegraph can be called the Google of code search. It's literally a search engine that allows you to search all of open source code and all of your private code. Right? So, what are the code search patterns we have with Sourcegraph? There are three types of search you can do right now, literal, regular expression, and structural. So, let's go to literal. I know many of us are familiar with the source-based component. If you're a new developer or you're trying to see occurrences of a particular class, symbol, or definition, you can copy the code base and paste it into Sourcegraph and it goes ahead to search for you. Right now, this is me placing the source components in Sourcegraph and it searches all of the open source code it has indexed across GitHub and GitLab and it tells me examples and results of people that are using source components across this GitHub and GitLab. So now you can see the responses. You can scroll down. On the left hand side, you can see all the filters and operators that you can add. So, you can search through divs, you can search through the time difference. You can search through the committers of the code. I can have access to how people are using certain APIs. Another API that you can talk about in ReactJS is the unstable batch of this. So you want to know how many people are using unstable batch of this in the world? How many people are using it and how are they using this particular API method? With Sourcegraph, all you need to do is paste it in. If you look at the arrow, it searches within the ReactJS organisation, it searches all of the repos within the organisation, and it brings you out results of every usage of unstable batch of this. So, from within the React code itself, and within every other example within the React organisation, you can just get results. Now let's go to regular expression. How many of us are familiar with regular expression? I know we probably don't use it every day, but with Sourcegraph, it allows you to flex your muscles with regular expressions. If you understand what you're trying to look for, you're trying to look for something within a file, for example. So, here, I was trying to look for how people are using some of the latest versions of React by using regular expression to search via the package.json of several repositories. So I pasted this into the Sourcegraph search engine. I toggled on the regular expression mode, and this is the results it gives me. So with this result, you can see, and you can narrow down to get the results of how many people or how many projects are dependent on a particular version of React. So some of us here are open source maintainers, some of us are open source authors. You really want to get an idea of how many people are using your open source package, or how many people are using certain versions, maybe because you need to deprecate certain methods or maybe because there is a new architectural change you need to work on. So with this, you can easily scroll and see how people are using it, Webpack, RemixRun, Visualiser. You can see how many people are really dependent on a particular version of your project. So this is an example of me searching through branches, right? I was searching through the Sourcegraph repository, and then specifying with a regular expression to search within every branch that has mchap within the name of the branch. So this goes into all of the branches that has mchap within it, and then searches for Ubuntu latest. With that, it returns all the codebase for me. This is just open source code. And then connect all your private repositories as well. If you sign up and connect your private repositories, it's the same result it gets you. It searches within the scope of all the repositories that you've connected to Sourcegraph. And then we have the structural search. I think this is one of my best types of search. With structural search, you can literally take blocks of code. So you can take if conditions, try to catch a full block of code and paste it into the Google search engine, into the Sourcegraph search engine, and it's going to give you the results you're looking for. So this is me searching through the Google organisation on GitHub and looking for this block of code. If not path.length, and you have the three dots. So it goes ahead and looks for all the types of code that fulfils this particular condition and returns them to me. So now I can see all of the projects and all of the codebases, all of the files that have this within them, and then I can keep narrowing my search. There are so many keywords that you can use. In fact, we have a boot out there with a cheat sheet, so I encourage you after this talk or when you're free to come out to our boot and get the cheat sheet. There's a lot of things to learn there. So why you actually need Sourcegraph? Developer velocity. As your team is growing, you want, you know, as you build more features, you want your developers to move very fast. So with Sourcegraph, if you have all your repositories connected to Sourcegraph, it allows them to search stuff, right? Some people, we get into a company, and within the first week, they're already committing code. They can easily get the codebase, right? For some people, it takes three weeks because you have to go through different repositories, you don't know what you're doing. With Sourcegraph, everything is in one place, and it allows your developers to get on quickly to the codebase. And then with refactoring, there is no case of I left this behind. I forgot. I know you have tests. Yeah, that's very good. But when you have shared systems, for example, you have a shared design system they're using across different repositories, sometimes you forget that a particular component or something is used in this other part of the codebase or in another repository. With Sourcegraph, once you paste that in, it brings out all the references from all the different repos, no matter how many repos, 100, 200, 1,000, connected to it, and you get all those references and you move fast. Now a recap of the search parameters. Again, there are different keywords you can use with Sourcegraph, right? This is just a very good illustration of some of those keywords, right? You have the repo keyword that allows you to search within a particular repo or within an organisation of repos. Then you also have the branch where you can specify the branch to limit and narrow the search. You also have the type symbol. With type symbol, what happens is instead of returning the code with the function call, it just returns the definition of the class or the definition of the function with type symbol. So, with file 2, you can limit it and say, hey, I want you to just search within the config files or within the package files. And then with type commit, you can say, hey, I want you to search within a particular commit or within a div. Then you can specify the lang, for example. If somebody is trying to learn about lambda functions in Python, you can type in lambda and narrow your search to Python and it will give you all the ways lambda function has been used in the world or within your private codebase. If you want to learn more about code search, I implore you to visit learn.sourcegraph.com. Learn.sourcegraph.com is our entire suite of learning tutorials for everything that has to do with regular expression search, structural search, and everything that you can do with code search. And then we have more resources. We have an active presence on Dev 2. We have our blog. We also organise what we call Dev 2 time. So Dev 2 time happens biweekly. So if you go to our YouTube channel and search for Dev 2 time, you can see the amazing set-ups of different developer workspaces. And then you can search our podcast as well. So all these resources, you can use it to learn more about code search and about Sourcegraph. So thank you very much. And then you can follow me on Twitter and on GitHub and ask me as many questions as you want. Thank you.


Prosper Otemuyiwa

Full-stack & typesafe React (+Native) apps with tRPC.io

Hello, I'm Alex. I'm here to talk about full stack React and TRPC. I've been making websites for a really long time and been working with React since 2016 or so. I've also worked a bit as an iOS developer and whatnot. Today I'm here to talk about APIs. I know this is a content conference, but just bear with me. You'll realize it's not that hard. So to break it down, let's start with the question, what is an API? So in the context of HTTP, very simplified, an API is just a way of calling functions on another computer. And the way we make and use APIs today might look something like this. We start with an API contract or schema because we want to have some guarantee that our API is actually returning what we want it to return. And then we might write code generation in order to help our backend logic on what it needs to return. And then once we've done our backend, we write an API query on our frontend, which then might have some code generation attached to it to generate a nice use query hook that we can use at the end. So I think there's quite a few steps to doing an API today. And the reason for this, as I see it, is that we have decoupled our backend and frontend completely, or rather that we have made them disjointed. But what if our backend and frontend didn't have to be decoupled? There are tools today where we can write the same sort of language on the frontend and backend and mobile. And one of those tools is TypeScript. So TypeScript is a good language which you can use everywhere. And I've been working hard over the last 10 months to create some set of tools to simplify the sort of API development with your React apps. And yeah, I'm here to introduce tRPC. tRPC is a toolkit for making end-to-end type safe API in a very easy manner. I'm just going to dig in to show you how it looks like. So when you write a tRPC backend, you start something like this. You have a router where you nest all your queries. And here is a query called hello. So we call this a procedure in tRPC. You can also view it as an endpoint. And all that this function does is that it returns some data. And when we then use this in our frontend, we get straightaway auto-completion of all our API endpoints. And we get the data inferred from your function in the backend to your frontend. And this doesn't rely on any code generation. It's just a bit of an abuse on the TypeScript compiler. And it's a thin wrapper around React query. And what you see here works exactly the same in React Native. And if you want to, you can incrementally adopt tRPC to your project, or you cannot use it at all if you don't want to. So let's see a bit more complex example. Here we have a backend that is actually talking to a database. So you can see here that we have a post by ID query. And that takes some input data through a validator. And you can see that the types of that validator is inferred straightaway to the frontend. And then at the end, you can see that we are talking to a database through an ORM called Prisma. And that gets some data back that is also then inferred straightaway on the frontend. So I started working on this open source project to scratch my own itch around January. And since then, it's gotten quite a lot of traction and a lot of companies are using it in production already. It's really well tested and I would really love for you to check it out. It's used right now for everything from COVID vaccination bookings to insurance companies to grocery delivery apps. Obviously, this is lightning talks. I want to be able to cover all the features of gRPCs to mention a few of what you can do. So that have mutation help us. This is a similar way that we have the use query stuff that I just showed you. We can do painless SSR and we can do a lot of other stuff as well. I'd love to hear from you if you love or hate gRPC. You can reach me on Twitter at Alex.js or by email on Alex at gRPC.io. Thank you.


Alexander Johansson

Vue.js Live Conference

Vue.js London Live 2021

Optimising Developer Experience with Nuxt 3

JSNation Live

JSNation Live 2021

How to Code Boring Internal Apps 10x Faster

Hi, my name is Chris Smith, and this is a talk on how to build boring internal tools 10 times faster. I am a developer advocate at Retool, which is the screenshot of the product you see here. And a little bit about me, I'm a hacker at heart, started playing around with QBasic when I was in middle school and messed around with Visual Basic and got really passionate about the visual abstractions of code. And that's really been the theme of my career. And what led me to Retool, and the Retool exists to help engineers create valuable software really fast. And I think that's a really fascinating vision for our company. And so our focus is on internal tools and building internal tools much more quickly. And you might be wondering what is an internal tool. And just think about all of the admin panels, the CRUD interfaces you've ever built, the custom internal apps. And these kind of exist in combination with all the software you'd write for your external customer base, say your marketing site, your products, if you're a SaaS company. And they're often slightly different from or extending off of your other internal apps like your CRM, your customer support tool, your marketing automation platforms. And pretty much every company ends up having to write a bunch of custom software for internal ops and processes. Some examples of these are things like contract renewals and loan approvals and DevOps and customer care. And they tend to be kind of cumbersome. But some things that define them is it tends to be a really well-defined problem you're trying to solve, some sort of business process that just needs to be done. And there's often a lot of time pressure. They need to be done yesterday because they're blocking some process or team. And they're used by internal people to your company, meaning not all the same requirements exist or the same stringent maybe design requirements. And so if you start doing this from scratch, you end up building a whole lot of boilerplate code. You got to find the right components. You end up with slow dev cycles, waiting on other teams to merge your code. And you end up needing a lot more expertise in CSS and back-end interfaces to make it all work. And so this is why Retool exists, is to solve this problem specifically. And the way we've gone about solving it is to build a drag-and-drop user interface that allows you to drag different components that are pre-built into this UI really quickly, a bunch of pre-built database and API connectors that allow you to quickly connect to those different services. And then the ability to write custom JavaScript anywhere across all of these different items to make all of the logic work together. And so in the interface itself, you can start with, say, a blank UI. And you can go and drag, say, a table in and say, then open the bottom panel for a query. I have Postgres here. I'll just say, select star from users. Do this. It looks good. Let's save it. And let's tell this table to reference the data from that query. So now this table is pulling in this user's table data. And I can also go in and start adding in some other things, like a container here, or maybe a button to take some action on that data. And maybe a header for that. Let's give it a name. And I can go in and inspect all of the data associated with this app, all the components on the left-hand side here, see the query values, see the individual tables, say, selected rows. And that hopefully gives you a quick idea of the app itself and how things are connected together. And since this is a really short talk, I'll just go through some of the things that I think are really cool about this. Because once you can start to compose these different components together, you can build pretty sophisticated internal tools, like this account dashboard, or this asset management interface for managing different files, or extend your current SaaS tools, like Salesforce, and build this really better note-taking interface on top of your CRM. And the focus of all this, really, is that it's a tool built by engineers for engineers. And so some of the things that we do to make that really easy for an engineer is expose all of the metadata, and context, and properties of these individual components, so that you can really quickly write the code you need to make all the components work to build the application you want to build. A whole lot of really easy-to-use database and API integrations, as well as the ability to connect to any open API endpoint. And so there's tons and tons of components that are pre-built. And you can also extend these and build your own custom React components if you want to. And as you're doing all this, you can really write JavaScript everywhere. We've tried to make it possible to have an escape hatch to just code whatever you need anywhere across the entire app, like using this math.round function, or setting table background colors using conditional operators. And we'll auto-suggest, as you're writing in curly braces, all the different objects or methods that we think are available to you. We'll also introspect the schema of your SQL databases or your GraphQL endpoints, and use autocomplete to show you which data to return. And as I mentioned a second ago, you can build your own custom React components if you want to, or pull in your own custom JavaScript libraries, which you can then reference anywhere in the app. And I mean, there's so much more here. You can do custom authentication support. You can deploy it locally into your own on-premise virtual private cloud if you need to, and sync it with your own GitHub instance. So I hope this is helpful for you as a potentially new, interesting tool. Let me know if you have any questions. You can find me at CLSSmitty on Twitter. And you can try it out at retool.com. Thanks. Thanks for watching.


Chris Smith

#developer experience