3 ms·
I don’t quite understand why this pattern would be necessary. I would prefer to render a ‚loading‘ state for dynamic components at build time, hydration sees a
by dgb23 7y ago
I don’t quite understand why this pattern would be necessary. I would prefer to render a ‚loading‘ state for dynamic components at build time, hydration sees a valid state and the user gets a clear indication of what is going on. Am I missing something?
- throwanem 7y agoNo. This is a useful technique in the case where that's not feasible, but the choice of example is infelicitous in that rendering a loading state (or the unauthenticated nav, maybe) would be fine.
- dgb23 7y agoI have to admit that I didn't use Gatsby for anything serious yet outside of playing around with it so my genuine question is: In which case wouldn't it be feasible? Asynchronous state updates regardless if they come from UI events or data fetching should be handled the same on the rendering side in my mental model. This has nothing to do with SSR/SSG. If one would just write client side rendered code as if the whole application was a SPA, then this problem never arises as long as there is a clear separation of concerns between GUI and state management. A React component doesn't have to know where its data is coming from nor where it is rendered. Wrapping a component in a 'client only' higher order component seems to add unnecessary complexity and brittleness by complecting the rendering tree with side-effects and state management: What if at some point there needs to be a different render of this component with data fetched during build time? In my opinion the example illustrates how moving state management out of components (Redux and so on) is a more sane idea, compared to encapsulating local state and side effects into components.
- morokhovets 7y agoCrawlers will see loading indicators instead of content. This is not what you want if you want your content indexed.
- dgb23 7y agoI suspect you misunderstood the article: The component in question should not render content during build time, it is a UI element that represents the login state, which you certainly do not want to have pre-rendered at all, let alone be indexed.
- morokhovets 7y agoI misinterpreted your comment. Thought you were talking of SSR pattern in general.
- joshwcomeau 7y agoOften, the data lives in localStorage, so it isn't really "loading". If your data needs to be fetched asynchronously, a loading state is a fine solution. Even in this case, a loading solution works just fine, but it's the exact same pattern. You'd just `return <Spinner />` instead of `return null`. You also face the same issue, if you don't wait until post-mount.
- dgb23 7y agoI personally would rather defer reading from localStorage than defer rendering a component. I don't want my components to know when and where they are rendered.