hey @tony.kay did you ever get the new workspaces demo back online? It seems broken here: https://github.com/fulcrologic/fulcro-incubator/blob/develop/dynamic-routing.adoc#full-example

wrong branch in the URL

https://github.com/fulcrologic/fulcro-incubator/blob/develop/src/workspaces/fulcro/incubator/routing_ws.cljs

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

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?

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? https://github.com/fulcrologic/fulcro-incubator#pessimistic-mutations

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

@souenzzo did you see this section? http://book.fulcrologic.com/#ReturnValues

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