Tom Dohnal

Sebastian Markbåge (@sebmarkbage), Andrew Clark (@acdlite) and Delba De Oliveira (@delba_oliveira) discuss server components vs client components, suspense, server actions and future plans (built-in animation API!). Read the notes or watch the panel discussion (link below) How do you think about React? – a way of authoring UI experiences in a way that feels natural and is composable (not important if you call it a library/framework 😄) – React team creates boundaries/concepts that enable others to use them to build their own building blocks What are server components and why we have them? – React is trying to integrate things that used to force you break outside of the component model (e. g. data fetching) and integrate them directly into React itself – a part of the React tree is moved to the server, several benefits – low-latency access to data (avoid waterfall problem) – direct access to database – you can create an ORM / security layer – some parts are a bit annoying to learn, but once you learn it, you unlock a new ecosystem Thinking server components vs client components – you can build an entire feature end to end within the React component model, no need to build a separate UI and API layer – client components aren’t escape hatches, they are a part of this new model, it’s okay to have loads of client component if you have a lot of interactivity, server components are just another tool in the toolbox How do server components work – React renders the component tree on the server – once it hits a client component, it needs to serialize it, and when doing so, if it discovers that the client component has a child server component, it optimistically renders that component on the server as well; the goal is to avoid extra round-trips Streaming with server components – before suspense: everytime you need to access data from the server, you need a loading state, you’d end up with spinners all over the place – original suspense idea: decouple loading state from where the data is fetched – now, you add the suspense boundaries if you wanna show the app in e. g. 2 or 3 stages, gradually streaming, instead of putting spinners wherever you need to fetch data Suspense for data fetching – server components are suspense for data fetching! although it’s not called like that by React team – in the future, offline-first with data sync might be also explored Server actions – a more convenient way of utilizing browser form APIs – actions don’t have to run on the server – oftentimes, action will cause a change to the UI, with actions, you can invalidate caches on the server, and React can send you the updated UI given the new data Future plans – built-in animations API – native support for mobile and offline-first experiences

Evan You (@evanyou) talks about recent improvements in Vue and future plans including Vapor mode in his talk "State of the Vuenion" at VueConf US (@vueconfus) Script setup + TypeScript DX improvements – initial options API wasn’t designed with TypeScript in mind – composition API – TypeScript as a first-class citizen – defineProps – can accept imported or intersection types – support for generics with <script setup lang="ts" generic="T"> – defineSlots – new macro to type slots Reactive Props Destructure – before, destructuring properties would break reactivity for that property as it’d no longer be connected to the original object – new compile time processing to make destructured properties stay reactive (experimental) defineModel – previsouly – a lot of manual setup for defining custom models (defineProps, defineEmits, :value="modelValue", @input="onInput", …) – new (experimental) – defineModel() and connect via v-model Getter support via toRef and toValue problem: passing non-ref reactive state into composables – useFeature(toRef(props.foo, 'bar')) – doesn’t track foo presence – useFeature(computed(() => props.foo?.bar)) – unnecessary computed tracking – useFeature(() => props.foo?.bar) – efficient and succinct – in your composable, you can use toValue that can accept either a ref of a getter, you don’t need to implement any conditionals Plans for 3.x minors – stabilize Suspense – built-in safe teleport – more efficient computed invalidation – SSR improvements (lazy hydration, validation for common causes for hydration mismatch) Vapor mode – new compilation strategy – more performant, no virtual DOM – templates stay the same 1) runtime for core features (now) – v-if, components, hydration compatibility 2) compiler for core features – shared codegen IR (intermediate represantation) for JSX and templates 3) integration – opt-in at a component level (e. g. only performance-critical parts of your app) 4) feature parity – Transition, KeepAlive, Teleport, Suspense

Kent C. Dodds (@kentcdodds) talks about progressive enhancement – leveraging native browser mutations, pros and cons of SPAs and progressive enhancement in Remix – in his talk at CityJS London (@cityjsconf). What is progressive enhancement? – you have a baseline UX for your app and then use capabilities of the device to improve the experience – e. g. a pizza shop that can get the location using the geolocation API if available – JavaScript can be used to progressively enhance UX of a web app Interactivity using native browser mutations – you can use forms and submit buttons to perform browser mutations – use hidden inputs for things like IDs – buttons can also have names and values if you wanna trigger different actions for different buttons (e. g. save vs delete) Why was web so much easier before? – the multi-page app mental model was easier: – user submits a form → user gets a new page, no state management Why are we developing SPAs then? – no hard refreshes, smoother UX – SPA capabilities are better than MPA capabilities Remix and progressive enhancements – uses native HTML controls and progressively enhances them with JS – e. g. loading state: by default, the browser favicon is loading or you can track the loading state using Remix’s APIs and display contextual loading indicators – no useState or useEffect in your codebase! Optimistic UI – hard to perform a rollback if the optimistic scenario fails (e. g. due to a server error) – Remix automatically revalidates the form state and makes sure the page is in its correct state

Matan Borenkraout(@matanbobi), Testing Library maintainer and senior software engineer at Microsoft, explains how JSDom works, why screen.getByRole(…) is so complex (and slow) or why you should user user events instead of browser events when writing tests. Read the summary or watch the talk (link in the thread)