![]() Testing the data-flow logic only without the presentation layer. 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. 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.Īlso, 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. I’m getting really sick of coding in this way and having a reactive language would save a lot of mental stress. 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. 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). I’m still a bit skeptical of electric in its current iteration (though I’m fascinated to see where you guys take it). Hasura does this for graphql subscriptions through polling. Saving the newest version of the data on the client side and only calling remote updates when necessary. What cache are we talking about? Offline mode we haven’t tackled yet. Quiz to check your understanding: what is dom/text ? ![]() See demo-2-toggle - clone the repo and run the demos it takes 20 seconds - you’ll see the functional effect system maintain the DOM in response to the atom changes. Note it’s not just try this is the case for all control flow operators - if, e/for, try/catch etc. Because all the interesting work is done by Electric & Missionary, electric-dom is only 300 LOC. ![]() This resource management of the DOM is performed by a functional effect system ( Missionary) which guarantees that all the resources are constructed (mounted) and destroyed (unmounted) in the right order, per the DAG. Here with try, the catch body mounts when Pending is present and unmounts when Pending “goes away.” (dom/div. Now, I guess I’m supposed to know that when the server does respond information is available, that the tr will be inserted?, and I’m supposed to know that the "loading" will be removed from dom/props ? Therefore, there may not even be a Pending exception at all, because maybe the server information arrived before the client was ready to render it! For more info about the network planner see UIs are streaming DAGs. ![]() The server client does not need to ask the client server for anything at all the information simply shows up. The client/server coordinate in advance like a sports team so this isn’t RPC. It looks like if the server doesn’t respond right away-which is expected The same way you organize your cljc projects today How do you organize your projects given that there may be bits of server and client code scattered in a lot of places? Is the intermediary code clojure? and is it viewable?Įlectric clojure is clojure and clojurescript code with reactive semantics. You can theme it any way you want, you can use standard tools like tailwind etc. We have a Postgres example in the Slack channel. Is this framework orthogonal to datomic? ie. Think of the GC as well - are you bothered the JVM or JS engine manages memory for you? We just decided to manage the network too. Why not let the computer take care of it? The separation of frontend and backend creates a boundary you now have to manage. I’m wondering why you guys have done it this way as it goes against the whole idea of ‘separation of concerns’ and actually embraces the opposite of that. How to try it: git clone the main repo and run clj -A:dev -X user/main, demos are in src-docs. Please try it! What do you think? We’re all looking forward to your feedback!
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |