Fork me on GitHub

Fulcro 3 News: I’m working on some design docs and prototypes around some pretty dramatic improvements for Fulcro 3. One of the biggest ones has to do with improvements around the transactional semantics and their composition. As the community and I create more and more complex applications with Fulcro we have added a number of improvements to help deal with the original design weaknesses in the platform. We’ve come up with some reasonable solutions, but I’m hoping to take it to the next level. I’ve written the following RFC around the mutation/load story. This is less about API and more about semantics/operation…so don’t get too fixed on any specific syntactic/API detail you might see. I plan on doing Fulcro 3 in a new set of namespaces so that the library can continue to be 100% bw compat with Fulcro 2, and hope that porting will largely be a job of changing a few require statements. If you’ve been using Fulcro for a while or are otherwise interested, please read the following RFC and leave any feedback on issue 305: @currentoor @wilkerlucio @mitchelkuijpers @nickowsy @claudiu @thheller @nha @levitanong @mdhaney @j1mr10rd4n @thosmos @f.o.thome @souenzzo

👍 11
🚀 5

Feel free to browse the other Fulcro 3 enhancement issues while you’re there.


I plan to write a heavy client side application and intend to keep the state in local storage (so no server backend). In the future I might enable a way to let the user sync the data with a server. Would this let me easily swap up local storage with a server in the future?


Yes. You may find these useful for the persistence:, You could build the remote queries using (Pathom uses the same graph query notation as Fulcro).


There is lots more info on managing state throughout the book:


Thanks! Still trying to figure out how it all works, very different compared to how Rum is working


Another question, say I have this db structure and I want to show all the todos where :todo/planned is equal to :system/current-date grouped under their todo list – can I express that with a query or would I need to query both and filter manually?


@mail228 as far as I know you would have to query both and filter, but I would be curious to hear if there is another way.


@mail228 the thing is, you wouldn’t necessarily have to query both depending on how you application works. For example, if I were writing this application and I found that getting today’s todos (or a specific date’s todos) for a todo-list was a common task, what I might do is write a resolver on a todo-list (I’m using Pathom terminology here; I’m not sure what you are using for your backend, if you have one) named something like :todo-list/todos-by-date which would take a date as a parameter. Then I could just query for that and the filtering would happen on the backend.


I just read your message above, indicating that you are running fully on the client-side, but what I said still applies. Again, if I was writing this I would consider using Pathom as a remote running on the client-side. And do the same.


Yep, for now it's just client-side but I would like it to be backed by local storage (preferably IndexedDB so I can save files/images too). In the future I'll probably add a server


Querying by date will be a very common task (a specific date not necessarily today) and for other entities than just for todos


I'm still trying to piece all the things together but so far it seems I need Fulcro for UI, Datahike for database, Konserve for persistence (of Datahike) and Pathom for querying the database (async?)? Pathom sits between Fulcro and the DB?


@mail228 you just introduced me to Datahke and Konserve, I didn’t know them; thank you 😛 But yes, regardless of your database, Pathom would sit between it and Fulcro


(but take what I say with a grain of salt, I’m not experienced at all with Fulcro)


The approach of querying for both the date and all the todos and then filtering would likely work fine if you don’t have too many todos, but isn’t as clean and would lead to performance issues if you have many todos.


If you follow the approach I suggested, I would also advise you to use something less generic than :todo-list/todos-by-date if possible. For example, you could have :todo-list/todos-due-today if all you ever care about is getting today’s todos.


Or :todo-list/todos-due-soon, which lets you push the “due soon” logic to the backend/whatever resolves the remote, instead of that being in your UI component