Fork me on GitHub

hey @tony.kay did you ever get the new workspaces demo back online? It seems broken here:


wrong branch in the URL


ah so this is for the source — I thought there also was a running workspaces example on github pages


Trying out the router example, seeing this warning:

[  7.575s] [fulcro.incubator.ui-state-machines] Attempt to get an ASM path [:fulcro.incubator.ui-state-machines/local-storage :pending-path-segment] for a state machine that is not in Fulcro state. ASM ID:  :RootRouter2
Still works, but is this a mismatch b/w router and state machine behavior?

Björn Ebbinghaus12:12:27

Do I place not changing values, like the label of something, in props or in computed? What would be best practice? And if I put them in computed, how do I tell workspaces, that my component should have these computed values?


@mroerni usually computed is for thing you don't control, when you use computed you are most of time delegating the control of it to a parent, while things on query the component will have direct control, its more about how you organize your things, if want that kind of control in workspaces you can use a custom Root, so you can provide anything you want, a lot of times when I need that I just write a new component (regular with ident, not a root) and wrap it just to create the card


Is it correct to issue dr/change-route inside ::uism/handler definitions?


The use case is building on the state-machine example to route to the app once login is successful. I guess dr/change-route is impossible inside the handler because we don’t have access to this, should I use dr/route-immediately or is some other pattern preferred?


That’s my bad…there should be a helper that lets you update app state for routes so they can be used in UISM


I’ll have to think about that, though…the router supports side-effecting for deferred routes.


at the moment you’d have to “cheat” and save the app or reconciler in a top-level atom so you can get to it.


you could also store/retrieve the reconciler as event data, but if you do that be sure to put the reconciler itself in metadata so it doesn’t hose your app state…e.g. (uism/store env :reconciler (with-meta {} {:r reconciler})) and (-> env (uism/retrieve :reconciler) meta :r)


I didn’t save either the app or reconciler, but just saved the login result from the uism in a global key, and exited without routing anything. In the defsc-route-targets, I put checks against the global key and reroute there. Is this OK, you think?


if it works 🙂


My (app/login {:user 123 :pass 321}) "returns" {:user 123 :authed? true} (on server) On client, I optimistically redirect the user to the "home" How can I handle it back to login page case app/login returns false ? It's something like "call me to merge this response"


@souenzzo I guess you and I have similar problems. I decided to just save the result of the login mutation in the client db (something like (assoc-in state [:globals :session :logged-in?] true) and tie the redirect to the value of that. I guess you can optimistically set that to true and overwrite it with the return value of app/login as well.


But where I say "call this mutation when app/login returns"?


app/login is itself a mutation, no?


I think you’re looking for pessimistic mutations maybe?


Nope. I just want to handle a mutation when it come back from server


client sends [(do-stuff)] server respond {do-stuff {:foo 33}} client take the response and do something with this response <<< HERE!


I think that is something with m/returning


yeah, returning should be the defsc symbol for the kind of thing you’re dealing with, and there’s also m/with-target


which says put the returning thing at at this path


Can I "wipe"/"reset" my db? (on logoff)


(get/save initial state)?


sure, just save your app state atom to an alt location at any time


then just reset! it later

👍 4