Utah Front End Conferences 2023 Edition - Part 1

Did you know that Utah has a vibrant JavaScript community? We even have a few local “tech celebrities” such as Tanner Linsley, Kent C Dodds, & Ryan Florence of Remix & React Router fame. With that community comes some great conferences, two of which include React Rally and the super local UtahJS Conf that I was able to attend this year! There’s a lot to talk about so let’s start with React Rally.

React Rally was held August 17-18 this year and was the 6th one I’ve been able to attend. As with all tech conferences starting back up after the pandemic, there was a fraction of attendees that normally show up. Hopefully next year’s numbers are better or we’ll start losing these kind of resources for education & networking.

You can check out the full schedule or watch the actual recordings if you’d like, but I wanted to comment on specific talks that I enjoyed or had interesting insights into.

This felt like one part marketing for Remix but another part taking a stab at what’s next for the front end industry and his bet is that the server is back baby! If you’re unfamiliar with Remix (or React Server Components with Next.js, the idea is to push some of the rendering back onto the server. This makes for some interesting advantages:

• More state gets pushed back onto the server that the client doesn’t need to maintain.
• Less code duplication (e.g. duplicated logic on the server & client).
• Leaning more on native web standards instead of intercepting them via JS and AJAXing all the things.

That isn’t to say that this is a return to full server rendering, but an attempt to find the happy medium between a rich client and server interactions.

Many companies are moving parts of their services to edge services. The idea of Edge Computing is to take the idea of CDNs with static files and include small, runnable services as well. This is often represented by pushing code to a vendor-specific runtime or pushing a docker image to an edge service.

This talk was about applying browser technology in the form or WebAssembly to edge computing. By pushing WASM files to the edge, you get a few benefits:

• Most vendors know how to run browser technologies like WASM.
• Because WASM is supported in most browser & browser-based server runtimes but is compiled, it can have as little as 1% of the footprint of a server or docker image which leads to faster deploys and less bandwidth needs.
• You can utilize WASM to do server side React rendering on the edge (supported in React 18).
• You can often have the same code on the edge as you do in your front end.

As a fan of component libraries, design systems, and component design in general, I loved this talk. Cory went through seven points on how to create reusable components:

1. Start with a small audience. Grow organically. This is mostly about YAGNI and knowing your audience. Sure, you could design a component that would work across the whole company but if it’s only needed in your project, maybe designing only for your project is the best and simplest way to do it.
2. Use a design system. This is about being explicit in the separation of design and components. He also mentioned that there are existing design system tools that help with this and one should be wary about using Figma only for the design system. This talk helped me solidify how important that separation actually is.
3. Start rigid. Add flexibility as needed. Similar to his first point, start out opinionated and only add additional props when they’re absolutely needed. Props are easy to add but difficult to remove as soon as someone relies on them. Keeping component API surface areas simple keeps maintenance simple.
4. Use third parties. Wrap, fork, or generate. The key takeaway here is to build upon existing work, be it wrapping a 3rd party component library, forking an existing one, or using a generator. I can attest to this as when building a component library at a startup, we built upon Material UI. It took a bit to configure it such that the app didn’t “look like a MUI app” but once it was done, we had components that already had accessibility built in, had great interop between components, was battle-tested, and had a well-documented API. Cory included some great examples of other component libraries one could build upon such as Radix UI, Chakra UI, Ant Design, & Aria Kit.
5. Honor HTML. This is about components using the same API as HTML elements do. His primary example was a Button component shouldn't have a text prop, it should take children like a button element does and handle it appropriately.
6. Use the Rule of Three. I think his shared quote helps with understanding here: “A reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.” - Jeff Atwood. Or maybe more specifically, “Try a component in three spots before placing it in a reuse library.” I tend to agree.
7. Docs, brand, publicity, and support matter. It should be easy to find your reusable components and related documentation. Key insights here:
   • Colocate things that are related.
   • Maybe use Storybook to be able to quickly see components and maybe even fork your root render based on an environment variable to render Storybook.
   • Include docs, but not by hand. Use something like react-docgen.

This talk had less to do with React & front end but was an interesting commentary on Asian hate crimes during the pandemic, systemic sexism in our industry, impostor syndrome, & cultural pressures put upon people. Shirley is an amazing artist who combines tech with art, which that alone made for a fascinating talk. I recommend watching her talk if any of that interests you.

Mark is one of the primary contributors to all things Redux and with that experience, was able to do a deep dive into how to tune rendering in React. The talk is worth watching but my key takeaways include:

• React renders; that’s how it works and isn’t always a bad thing.
• Rendering doesn’t necessarily mean that the DOM needs to update.
• Never define new component types (child functions that render) within a parent component.
• Calling setState isn’t technically async, but it does wait for a render cycle to update.
• flushSync() if you want to opt out of batch reconciliation.
• <StrictMode> will double render in dev mode to hopefully cause bad approaches to break while testing.
• Memoization:
  • There is a cost.
  • If props change on every render, there’s no point.
  • There could be a benefit from wrapping everything with React.memo but probably not worth the effort. A good tool to reach out for regardless.
• Context API will always re-render if anything changes so keep the context object small. If that doesn’t work for you, use a different global state library (like Redux!).

If you don’t know the reference, you should watch it. This talk was mostly about poking fun at odd things in React but I actually came away with some good takeaways:

• Stop calling APIs in useEffect. It’s error prone in so many ways and there are better ways of handling this now (e.g. React Query).
• Wrapping event handlers in useCallback doesn’t help you that much so don’t bother (I am super guilty of this).
• useSyncExternalStore is the closest thing React has to a state-management solution. Check it out sometime (but probably use a library that utilizes it under the hood).
• Lift state out, not up.

React Rally has been pretty great in the past and this year was no different. I was able to meet people from all over the country (and the world funny enough) and enjoy hanging out with fellow front-enders. Again, check out the recordings if any of these talks sounded interesting and I’ll see you in part 2 with UtahJS Conf!