Fork me on GitHub

you don’t need computed for things that don’t have queries


but you do need to pass js props instead of clj


(clj->js (assoc viewport :onViewportChange …))


unless you’re using a wrapper that already converts the props for you


ok, i ended up doing something similar, just merged them (ui-react-map-gl (merge viewport {:onViewportChange #(prim/transact! this [(api/update-viewport {:viewport ~%})])})`


exactly, yeah


weirdly enough, seems to work without the clj->js


you using the macro-create-element or something?


yeah the component-factory stuff from the incubator


those do it for you


thanks,. SN: That state machine stuff looks pretty awesome


I’m really excited about the SM stuff….been wanting to do that for a while, and I love how well it is coming together


Fulcro seems particularly well-suited for it


incubator 0.0.12-SNAPSHOT on clojars…a tested version of state machines that I’m happy with as a base. Might have more to add to it, but I think it is a good solid start


I just ported a hosted CC processing system (that has to send a submission through my server to a CC server, get back a URL, pop an iframe with the CC processing in it, all while dealing with possible errors everywhere in the chain) to use the new state machines. I deleted more code than I added, the code I deleted was complicated and hard to follow, and I got the new version right on the first try (sans two spelling errors on keywords). I highly recommend people try this thing for any bit of UI that has a sequence of complicated steps (login, form processing, wizards, etc.). I really think this is going to be a game changer for simplifying Fulcro apps even further.

bananadance 8
aw_yeah 4

I’m going to push a formal release on incubator..this is already very usable.


Hello, I am doing a side project with Fulcro, and I was struggling on how to consume a remote function that makes calculations, I need to receive the results in the response/hit for the mutation. I had to refresh my component using additional keywords in the mutation to obtain the result from the server, but this counts as a second request, no so efficient. Is there a way to use the responde from the mutation to update a component? . Thanks for your answers.


@U0SKL38CV Don't really understand u're use-case. Can you share some code or a concrete scenario ?


Might be what you're looking for

👍 4

@U3LP7DWPR, OK. I will check the link, and share some code in a moment. Thanks.


@U0SKL38CV If you're use-case is. a) Do a mutation on the server that returns some values b) Process the values returned from the server. Then you can chain the server mutation with one that does the processing with ptransact!


@U3LP7DWPR I think it is the first case, I am reading about Mutation Joins, It looks like my case, I need to return the value (calculated in the server) so Fulcro update the component and show in the browser, without additional requests.


cool, That's what the mutations joins are for 🙂


@tony.kay just wanted to say: the new FSM stuff in incubator is so cool! This is exactly what i’ve wanted for a while now. Thanks for continuing to build awesome stuff!


Thanks @levitanong I’m still having some ideas around it…right now it is written so you write mutations that trigger events…but since the state machine is really a “mega-mutation” I’m thinking about ways in which you could add loads and remoting into it, so they you could use a state machine instead of mutations. We’ll see where it goes, but yeah, I’m liking it so far.

parrot 12

this dovetails again into re-frame v. fulcro discussions. I've glued automat and re-frame together to achieve something similar. Was fun, worked well, etc. but um, that was time that didn't directly contribute to functionality lol


I’ve not written anything of size with re-frame, so I can’t really speak to relative advantage. I will say that they way Fulcro is structured is lending itself very well to direct integration that feels a lot more seamless that even I expected.


Fulcro’s integration of queries, state, normalization, and components means that IO integration is going to be pretty simple and powerful. The result of a load could simply be mapped to a SM event. e.g.:

(uism/load this :stuff Thing {:post-event :loaded! :error-event :load-failed!})
loads would not make sense unless they affect known actors. Post mutation semantics would apply for the post event, and the error event would take the place of fallbacks. Same could easily be done for pmutate as an event with phases. it’s really quite appealing. I think those additions would take almost no effort; maybe three new uism mutations and load/pmutate wrappers that trigger them with params. But then there’s an additional complication: dynamic actors, but adding an actor due to a load event looks pretty easy.


At that point your hand-written mutations disappear and become state handlers, and your UI code does nothing but trigger! state events.


It’s overkill for simpler UI stuff I think, but so many of the more complicated flows in UIs will benefit greatly


I thought about using something like automat, but the direct approach seems more seamless and approachable (and doesn’t introduce yet another dep you have to learn). One disadvantage to the current design is that the state flow is not (easily) “tool readable”…I can’t generate diagrams of the machine for you. I’m not sure it matters. Most of the stuff I write in UIs, at least, can typically be represented with a handful of states that don’t really need autogenerated diagrams.