48 Matching Annotations
  1. Aug 2021
    1. All consumers that are descendants of a Provider will re-render whenever the Provider’s value prop changes
    1. It's time to put some of these pieces together. We know that: Calling setState() queues a render of that component React recursively renders nested components by default Context providers are given a value by the component that renders them That value normally comes from that parent component's state This means that by default, any state update to a parent component that renders a context provider will cause all of its descendants to re-render anyway, regardless of whether they read the context value or not!.
    2. Immutability and Rerendering 🔗︎

      This section is gold to use as a teaching example

    3. All of these approaches use a comparison technique called "shallow equality". This means checking every individual field in two different objects, and seeing if any of the contents of the objects are a different value. In other words, obj1.a === obj2.a && obj1.b === obj2.b && ......... This is typically a fast process, because === comparisons are very simple for the JS engine to do. So, these three approaches do the equivalent of const shouldRender = !shallowEqual(newProps, prevProps).
    4. When trying to improve software performance in general, there are two basic approaches: 1) do the same work faster, and 2) do less work. Optimizing React rendering is primarily about doing less work by skipping rendering components when appropriate.
    5. After it has collected the render output from the entire component tree, React will diff the new tree of objects (frequently referred to as the "virtual DOM"), and collects a list of all the changes that need to be applied to make the real DOM look like the current desired output. The diffing and calculation process is known as "reconciliation".
  2. Jun 2021
  3. May 2021
    1. The thing that makes the client-side invocation return the same data as the server-side one is that the results of calling fetch during SSR are serialized and inlined into the page. This ensures consistency when the page hydrates, and saves network round-trips (and also means less data needs to come over the wire, since everything can get compressed using the same gzip dictionary or whatever).
  4. Apr 2021
  5. Jan 2021
    1. Maybe $$slots like $$props? My use case is that I'd like to wrap a slot's content in an element that applies styling that I'd like absent without the slotted content. Something like this: {#if $$slots.description} <div class="description"> <slot name="description"></slot> </div> {/if}
  6. Dec 2020
    1. Preload functions are typically used to load data that the page depends on, hence its name. This avoids the user seeing the page update as it loads, as is typically the case with client-side loading.
    1. I put together a POC that resembles react-rails and helps with server- and client-side rendering, and provides a view helper (svelte_component):
    2. webpacker-svelte misses server-side rendering, though.
  7. Nov 2020
    1. There is no rerender, when you call listen, then all scroll events will warn on chrome. See this entry from svelte: breaking the web

      Even the author of this library forgot this about Svelte?? :) (Or maybe he didn't and this response misunderstood/falsely assumed that he had.)

  8. Oct 2020
    1. Node doesn't have a DOM available. So in order to render HTML we use string concatenation instead. This has the fun benefit of being quite efficient, which in turn means it's great for server rendering!
    1. The original promise of React was that you could re-render your entire app on every single state change without worrying about performance. In practice, I don’t think that’s turned out to be accurate. If it was, there’d be no need for optimizations like shouldComponentUpdate (which is a way of telling React when it can safely skip a component)
  9. Sep 2020
    1. useField() returns FieldRenderProps. It will manage the rerendering of any component you use it in, i.e. the component will only rerender if the field state subscribed to via useField() changes.
    1. Since you often want to do calculations based on state, Svelte also has the “reactive declaration” symbol, $:. It’s like a let declaration, but whenever any variable referenced in the expression — count in this case — is updated, the expression is re-run, the new variable’s value is updated, and the component is re-rendered.
    2. The heart of Svelte’s magic is “reactivity”. Every let declaration sets up a listener, where any time the variable is assigned to, the change triggers a render of the component. So when the increment function calls count++, the component will re-render, which will update the value shown to the user by Count: {count}.
    1. To change component state and trigger a re-render, just assign to a locally declared variable.
    1. I don't think componentDidRender is a substitute for componentDidMount because the component can render multiple times when props change after it's mounted once.
  10. Aug 2020
    1. In the two years that I've been working with React professionally, I've never come to a point where I needed to force a re-render. I encourage you to read the article from the beginning if that's what you're here for because usually there's a better way of dealing with React components that aren't updating.
    1. It's recommended to put the fetch in onMount rather than at the top level of the <script> because of server-side rendering (SSR). With the exception of onDestroy, lifecycle functions don't run during SSR, which means we can avoid fetching data that should be loaded lazily once the component has been mounted in the DOM.
  11. Jul 2020
  12. May 2020
  13. Apr 2020
    1. By rendering important parts of the application with the real data on the server-side, an isomorphic application can show a meaningful initial page. On the other hand, client rendering application can’t show any meaningful information until it fetches all external data it needs. In the meantime, the only thing a user will see is a loading indicator.
  14. Jan 2020
  15. Dec 2019
    1. server-side rendering is strict about configuration, and the best way to find out what's wrong is to compare your project to an already working setup. Check out the reference implementations, bit by bit.
  16. Nov 2019
    1. // require('hammerjs') when in a browser. This is safe because Hammer is only // invoked in componentDidMount, which is not executed on the server. var Hammer = (typeof window !== 'undefined') ? require('hammerjs') : undefined
    1. you can update the state right during rendering. React will re-run the component with updated state immediately after exiting the first render so it wouldn’t be expensive
  17. Sep 2019
  18. Aug 2019
  19. Jan 2016