4 ms·

>Do it at the top-level. Which top level? Requires a lot of coordination code, duplication, and coupling of your entire component hierarchy to each other no?

• nickdandakis 7y ago
  Not to mention you can still keep your pure UI components separate from your components that have data fetching logic (aka containers). Components are highly reusable. Containers are coupled to specific API calls or logic. I still default to doing as much data fetching on the top-level page component as possible and trickling data down. But if there's certain logic or data fetching I re-use in multiple places that don't need to block the whole page, I'll definitely refactor that into hooks + containers and delegate that data fetching lower in the tree.
  • PKop 7y ago
    Every one has reasons for their concerns, and complexity is something to be concerned of... but it seems most critics are arguing from a view which implies they don't support the "declarative component" model itself. These added features are simply extending that paradigm in a natural way that supports better UX, within the constraints of the javascript language. Nobody says they are easy problems to solve, but it's sort of a non-sequitur to argue alternatives that don't solve them (or don't absolve one of having to solve them still.)
• lhorie 7y ago
  > Requires a lot of coordination code, duplication, and coupling of your entire component hierarchy to each other no? Only if we tunnel-vision to a narrow definition of "idiomatic patterns in React". In Angular, for example, this is solved via a DI system. In React, you actually get much higher level of coupling because all orchestration-type things need to go through context providers (meaning a given component may only work if certain providers are installed at the top level of the React tree). In Angular, a coupling mismatch issue would throw an error saying X component requires Y dependency and the solution would be to simply inject what is missing. No need to go edit your layout file or whatever.
  • PKop 7y ago
    Definitely, if you want to say that another framework itself better solves all of the very real problems that need solving... makes perfect sense. The coupling I'm mainly referring to is within your own app hierarchy. Moving/adding components around within your app requires editing the long chain of component hierarchies and data dependencies. Yes injection works to solve, but isn't this similar to hooks (encapsulating reusable logic/data fetching)? Whether a top level Context provider (that will also throw an error if not provided) or injection.. is there much of a difference? And does this not seem less coupled than prop drilling through the entire component chain? In the context of a discussion about UX, loading states, spinners, concurrent rendering though, does Angular address this? I'm not that familiar with it..
    • pault 7y ago
      Not being able to move your components without editing your component hierarchy is a code smell. Data should be bound at the level it is consumed. "Prop drilling" is an anti-pattern. Redux is the most common way to solve this problem but you can use anything built on top of the context API.
• nostrademons 7y ago
  > Requires a lot of coordination code, duplication, and coupling of your entire component hierarchy to each other no? It's basically the Law of Demeter applied to UI components, and has both the benefits and the pitfalls of the LoD: https://en.wikipedia.org/wiki/Law_of_Demeter https://en.wikipedia.org/wiki/Law_of_Demeter Boilerplate code goes up, method signatures get duplicated more (though JS has easy varargs & spread operators, so this can be minimized), method logic is less duplicated, and coupling is decreased. > Still doesn't solve disparities in data loading completion across different services. Render giant loading spinner or the entire app? You have a choice depending on product concerns. You can render a single loading spinner for the app. You can render individual spinners for different loading components (just pass the 'loading' prop into each of them separately), but have them all resolve at the same time. Or you can issue separate RPCs for each, as if the component had made the request itself, and have each component re-render as the request comes back. The nice thing is that this choice is not embedded within the component itself, so you could for example start out by rendering a single global spinner until a single global RPC comes back, and then as you build out the backend and separate calls into different RPCs, change component rendering to incrementally show the new data. > Plus, you will be overfetching if everything is pulled into top level components. Again, this is a product tradeoff. Do multiple components display data that changes when an event happens on one component? It makes sense to batch up the RPCs then, because they'll always be triggered together anyway. Or is each component displaying data that is manipulated only by that component? Then give it its own RPC, but you should still kick it off at the top-level and delegate up the tree so that you can change this behavior easily. In my experience, UIs designed by frontend engineers tend to have lots of RPCs that are both kicked off by and only affect a single component, while UIs designed by UI designers and CEOs (and users themselves) tend to have a lot of non-local changes throughout the UI in response to an event in one component. This is a source of tension between these groups, but only one side is signing the paychecks.
  • tomduncalf 7y ago
    Perhaps I don’t fully understand your use case, but would something like MobX solve the problem you describe? Keep your data in stores, components automatically react to changes in them. You could do the same with Redux but MobX gives you finer-gained rerendering (only components who’s data has actually changed rerender)