Fork me on GitHub

@sundarj Yes, The original Om Next design had the opinion (centered around remote interaction) that the server could not possibly know which data parts the client cared about. I have always disagreed with the opinion as an over-optimization, and in Fulcro 2.0 we won’t be tied to that decision anymore. So, I do plan on supporting some kind of declarative key list at the mutation level.


i see! great, thanks.


@tony.kay Keep thinking about this one. Know it's a really strange request but still... Is there any chance fulcro v2 could have a callback for df/load ?


I know that there are some updates coming up in v2 that provide some really nice functionality for optimistic updates and error handling.


The thing that I'm finding hard in practice is that I don't have only personal projects and: - I get designs/specifications that have loading screens & error handlers (changing that is not a option) - I have to collaborate with other people on the project and with only optimistic updates... there's just a good change not to many want to learn that much all at once - Using post-mutation as a callback is just to limiting and that post mutation in most cases is doing way more than it should be doing


Even though it might be "shoot yourself in the foot" material, think it might help a lot of people get on board and be productive a lot faster. Then once they get better and have a working app, refactoring it to have optimistic updates should be relatively simple.


@claudiu Doubtful. You have post mutation, and that is the model. You could treat it as a callback at your own peril already. - If you need to show an error screen you can. The post-mutation can detect merged data that indicates an error already. - You don’t have to use optimistic updates (already). Just block the UI at each remote interaction and have the post-mutation unblock it. Wrap that in your own transact so you don’t have to say it each time (e.g. blocking-transact and blocking-load) The only thing the current model specifically discourages is chained loading (triggering a load from a post mutation). As soon as we break the overall model by placing people in callback hell…load triggers callback, than then needs to trigger a callback, than then…. the framework becomes a lot less compelling.


The blocking transact could be done with the mutation merge handling right now…just make the default mutation merge be “unblock the UI”.


I think the whole thing feels a lot more clunky if you go that route, but I don’t think you’re actually limited here by Fulcro’s ability. “I’ll have trouble convincing my co-workers to do it” just isn’t an argument I find very compelling.


I just pushed an update to 2.0.0-SNAPSHOT that has the first version of the new history support. If anyone is playing along, it is on clojars. The demos seem to all work, and all tests pass. The new history support already has the following internal features: - Tracks when network activity was started, so it can keep history around for any activity still in-flight - History is now compressible! There is a compressible-transact! that tells the system that adjacent transactions can be combined in history to just the last one. This means that keystroke transactions can be compressed in history to be less annoying (and space-consuming) for support viewer. - History edges contain the tx, db-before, db-after, and tx-result. Also plan to add network result. This will make analyzing history a lot more useful. Some other changes/additions: I’ve turned merge! and set-query! into internal calls to transact!. This unifies the model so that basically the only way to go from state to state now is through transact!. Loads were already indirections through transact!.