Testing the data-flow logic only without the presentation layer. Would it be possible to strip out the ui/* stuff to compile it as an input/output block? It just seems hard to test otherwise.
Saving the newest version of the data on the client side and only calling remote updates when necessary. Hasura does this for graphql subscriptions through polling.
I’m still a bit skeptical of electric in its current iteration (though I’m fascinated to see where you guys take it). I’ll explain why:
This is code for a reactive type with react integration here that reruns the query when it’s arguments change with the ability to set remote and a local cached query (via sqlite). The implementation is pretty dumb and the calling code needs to be really explicit because there’s around half a dozen different ways that data can be updated. I’m getting really sick of coding in this way and having a reactive language would save a lot of mental stress. but having said that there are also benefits to coding this way as well, the primary advantage is that there is good separation between the data and ui and pathways can be tested independently, as do the components - which do not need to know about the network logic to work.
Also, data that is being pulled in by the app might be displayed in 10 different places spread across different components - so the tight coupling in electric may not be ideal in many of the use cases I’m familiar with. Having multiple components react to changes on a ‘view’ that can be updated via a number of methods is something I’m more comfortable with.
I think that having a schema on both the backend and the frontend is really important in reconstructing data graphs. Very interested in your thoughts on this.