Widget Driven Development
alexei.me
Widget Driven Development
1–10 of 25 posts
Re: Widget Driven Development
#2Would this work with server side rendered applications? We SSR a lot of the data calls, as the identifiers to be fetched is usually available in the URL.
——
Nvm, I see that’s listed as a React Query feature.
Re: Widget Driven Development
#3> [Widget Driven Development] makes the data flows transparent, architecture flexible, the code resilient and easy to test.
A direct quote from my "expert-junior-evangelical" phase. When I marveled at my own cleverness & marketed my brand-new paradigms to my unfortunate peers. Lots of assertions, few citations, no research. All the fun was in coding, not in studying books or even the industry at large. Then, business requirements changed and I was left to maintain over-engineered monolith of my own making.
After a few cycles of hubris, I learned the danger of selling fads as evolutions. It hollows you out.
Re: Widget Driven Development
#4And yet another round on the Web GUI carrousel.
Re: Widget Driven Development
#5The benefits seem unclear to me, especially how this solves the shared-state issue. Is it just that each "widget" calls the same API "manager" and propagates the changes to every widget in the event of a change?
Isn't this exactly what Redux already do if you use actions to fetch data and put it into the store, with the difference that each "widget" manage filters and state based on the fetched API data? Seems like it could create a lot more code with less re-usage, since every widget has to manage this themselves.
Re: Widget Driven Development
#6One problem is the idea that there is a one-size-fits-all solution. An application should be structured in such a way that it fits the problem that you are trying to solve as ergonomically as possible. 'Widget Driven Development' might be very good in some circumstances but not in others.
Re: Widget Driven Development
#7The benefits seem unclear to me, especially how this solves the shared-state issue. Is it just that each "widget" calls the same API "manager" and propagates the changes to every widget in the event of a change? Isn't this exactly what Redux already do if you use actions to fetch data and put it into the store, with the difference that each "widget" manage filters and state based on the fetched API data? Seems like i…
With pure Redux approach the mutation flow is more complex:
- send mutation request to Backend
- fetch updated data
- put the updated data in the Store
- see the updated data propagated in components
The suggested approach: - send mutation request to Backend - see the updated data being fetched and displayed by components
To me the second is much cleaner and easier to reason about
Re: Widget Driven Development
#8The benefits seem unclear to me, especially how this solves the shared-state issue. Is it just that each "widget" calls the same API "manager" and propagates the changes to every widget in the event of a change? Isn't this exactly what Redux already do if you use actions to fetch data and put it into the store, with the difference that each "widget" manage filters and state based on the fetched API data? Seems like i…
With pure Redux approach the mutation flow is more complex: - send mutation request to Backend - fetch updated data - put the updated data in the Store - see the updated data propagated in components The suggested approach: - send mutation request to Backend - see the updated data being fetched and displayed by components To me the second is much cleaner and easier to reason about
>Seems like it could create a lot more code with less re-usage, since every widget has to manage this themselves.
It might create a bit more code in components, agree. I think this is a fair price for the all benefits it brings.
That said, the total amount of code might be even less (no action-creators, reducers, etc.).
Also declarative nature of the libraries makes the added code very easy to follow.
Re: Widget Driven Development
#9One problem is the idea that there is a one-size-fits-all solution. An application should be structured in such a way that it fits the problem that you are trying to solve as ergonomically as possible. 'Widget Driven Development' might be very good in some circumstances but not in others.
Agree. There are applications where widgets approach would not bring much benefits.
Let say, applications with lots of UI state (state that doesn't exist on Server).
Also not sure how it would work with realtime apps.
It's the same with every approach, the are always exceptions from the rule.
That said, I see the benefit of this approach for the majority of UI apps, which heavily rely on Server data.
Re: Widget Driven Development
#10Earlier quoted context omitted.
With pure Redux approach the mutation flow is more complex: - send mutation request to Backend - fetch updated data - put the updated data in the Store - see the updated data propagated in components The suggested approach: - send mutation request to Backend - see the updated data being fetched and displayed by components To me the second is much cleaner and easier to reason about
>Seems like it could create a lot more code with less re-usage, since every widget has to manage this themselves. It might create a bit more code in components, agree. I think this is a fair price for the all benefits it brings. That said, the total amount of code might be even less (no action-creators, reducers, etc.). Also declarative nature of the libraries makes the added code very easy to follow.
The key thing to realise with widgets is that while the widget code is indeed complex, it’s reusable and generally you’re not writing it.