|
|
|
|
|
by Lx1oG-AWb6h_ZG0
2013 days ago
|
|
One thing I haven’t seen addressed is versioning: what happens when you push out an update so your server component now takes in a different set of props (or renders a different set of divs/spans/css than before?) Previously, the abstraction level between your server and client used to be APIs, with well-known patterns for versioning... this has now shifted to the level of component props, which I suppose is still workable — it’s very similar to graphql — but is certainly not very intuitive. |
|
In general, this isn't a new problem per se, as backend API changes can similarly break different clients that have been cached. Or when you deploy client code and the code-split chunks have changed. It's true that with this approach it likely becomes a more common problem.
One way to solve this is immutable deployments where the server runs the version of the code that the client is on. Many providers already do immutable delpoyments so there's possible integration there. It could also have some kind of a fallback where a coarser refetch is triggered when the versions become incompatible.
We expect that hosting providers will be innovating in this area in the future, too.