Fork me on GitHub
#fulcro
<
2021-03-21
>
zhuxun204:03:11

Is there a way to queue something after a transaction is done? I currently know two ways to do this: 1) put them in the result-action section of the defmutation. 2) use UISMs I was curious if there's an even lighter way. I wish I could do this ad-hoc for a particular comp/transact! call. For example, it'd be great if I could just do

... {:onClick (fn [] (comp/transact! this [(my-mutation {})] {:ok-action (...), :error-action (...)}))}

Jakub Holý (HolyJak)06:03:00

Yes. Make your own varianylt of transact :-)

zhuxun223:03:50

Thanks. Is that something you would do? Or is there a reason you wouldn't do it?

Jakub Holý (HolyJak)10:03:27

No, I do not do it. But if I had the need you do then that is likely the way I would take.

Jakub Holý (HolyJak)10:03:08

Normally the post-action is inherently related to the mutation itself so it makes sense to define those two together. But I guess from your writing that that is not the case.

Piotr Roterski16:03:27

Hey everyone! 👋 I've been putting off using Fulcro RAD in my project because I wanted to use Crux as a backend database instead of Datomic. However, I have run into a bit of a project structure mess during my exploratory phase so I watched Tony's video "Building Things with Fulcro RAD" and got inspired. In spirit of doing open source for one's own needs, I've developed https://github.com/roterski/fulcro-rad-crux 🎉! I based the plugin heavily on fulcro-rad-datomic - I adapted it to Crux API and cut down Datomic specific features... and it worked! Those few integration tests pass and fulcro-rad-demo seems to be working correctly with it too. I'm going to adapt my project to Fulcro RAD now and I'm optimistic that it'll cut down a lot of complexity. fulcro I look forward to hearing your feedback and I welcome any kind of testing, review and/or contribution. 😊

👏 33
6
Piotr Roterski16:03:03

I'm open to bringing it under fulcrologic namespace when it's vetted enough but until then I'm considering pushing it to clojars under net.clojars.roterski/fulcro-rad-crux - it's my first time publishing anything so I'm still figuring this out. If you want to use it now, you can follow https://github.com/roterski/fulcro-rad-demo and import it as a github dependency UPDATE: I've managed to push it to clojars already https://clojars.org/roterski/fulcro-rad-crux.

Piotr Roterski16:03:10

datomic features I've dropped include: schemas (crux is schema-less), datomic cloud stuff (crux config is much simpler, you just pass map into it) and the concept of native-id attribute (couldn't figure out if it's needed so I dropped it and want to see how far I can get without it)

tony.kay19:03:57

Native id support is meant as an optimization (so you don’t have to store a UUID datom), that’s all.

Piotr Roterski20:03:21

the main difference is that crux stores data per document, not per attribute as datomic so this datom optimization probably doesn't make sense anymore in context of crux - I was just worried it might break some RAD assumptions but if it's just an optimization then I'm less worried about it 😅

Piotr Roterski20:03:30

I really appreciate how flexible fulcro rad model is and I foresee that after using it more I could just add more crux-specific attributes to facilitate crux's unique features (like bitemporality) - this is just a first, most basic iteration

tony.kay21:03:07

I’m looking forward to seeing what you come up with.

❤️ 3
3
Thomas Moerman08:03:54

Very cool. Thanks for sharing this effort.

Thomas Moerman16:03:09

@UHA0AQZ2M is there a particular reason for maintaining the crux db in an atom instead of calling (crux.api/db node) on a globally maintained (e.g. using mount) node instance? thx.

Piotr Roterski16:03:01

@U052A8RUT thanks for digging into the details and asking the question. Honestly, the main reason for this is that I wanted to mirror fulcro-rad-datomic’s implementation as closely as possible to preserve compatibility and it uses the same pattern: https://github.com/fulcrologic/fulcro-rad-datomic/blob/develop/src/main/com/fulcrologic/rad/database_adapters/datomic.clj#L534 : “The atom is present so that a mutation that modifies the database can choose to update the snapshot of the db being used for the remaining resolvers.” I guess that it still would make sense with crux, right?

Piotr Roterski16:03:28

nevertheless, both nodes and databases are available globally on pathom env so you can use either one of them, but using database if nothing else saves you the extra crux.api/db call each time as convenience

Piotr Roterski17:03:23

you still could/should keep nodes on the mount maintained state as it’s done in the fulcro-rad-demo example https://github.com/roterski/fulcro-rad-demo/blob/develop/src/crux/com/example/components/crux.clj it’s just outside of the plugin’s responsibility

3
Thomas Moerman18:03:45

Thanks for clarifying!

🙏 3