16 Matching Annotations
  1. 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.
  2. Nov 2020
  3. 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!
  4. Aug 2020
    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.
  5. Jul 2020
  6. 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.
  7. 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.
  8. 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
  9. Sep 2019