@tony.kay Learned my lesson . no more profiles. It worked.

About the bug: On ubuntu 16.04 they provide only the latest jdk version through ppa. Even the latest open-jdk-8 update 191 appears to be affected. I had to install the previous version available of open-jdk-8 to escape of waiting 3 minutes on a clj A:dev on template

ooof. that sucks..

I installed the latest java a month or so ago…worked fine for my normal stuff, but I seem to remember Datomic didn’t like it, so I just went back to 8

I’m trying to figure out how to implement something like the stack navigator from react-navigation using the dynamic routing from fulcro-incubator (this is for a mobile app). The main issue is handling the ‘Back’ button on child screens. For example, from the profile screen you can go to a screen with a list of users, then the ‘Back’ button takes you back to the profile screen. But on that list of users, you could click on a user and go to their profile, etc. - and no matter how deep in the stack, the ‘Back’ button takes you to the previous screen. I’m thinking I need to create the ‘Back’ button handler in the parent screen and pass it as computed props to the child screen, but it feels like I’m missing something. Any tips?

The other option is just using react-navigation directly. This has the added advantage of giving us the nice animations between screens. I’m just concerned it will be tricky to integrate with Fulcro, particularly making sure there are union queries in the right places so we aren’t querying “the world” on every root render.

If you need a stack, you have to make a stack…nothing in incubator or Fulcro implements stack for you. That said, it’s a pretty simple thing: At each “forward-like” nav, read the “current route” from the root and push that onto a stack (in app state via a mutation)…it’s just a vector of strings. To go back, pop it off and chnge route to it. etc.

you’re basically just implementing a route history API…you’ll want to do things like limit the depth of the nav history, etc…but this is all relatively simple stuff to write and test as functions against immutable maps that you then apply via mutations (or a state machine of your own).

I’d probably make a singleton navigation state machine and have it track history (via the store/retrieve mechanism)…then you can send it events with event-data. The events would be things like :event/go-back!, and :event/navigate-to! with event-data that is the “current route” as a path vector that routers can use.

You’d probably need to keep a reconciler ref for use within that state machine…I’m trying to make an overall better design for that, but for now if you need to top-level side effect using the reconciler directly within a state machine (with a setTimeout to ensure the SM finishes before the next tx starts) is fine.

Thanks, Tony. That sounds like a solid approach. And I’ve been looking for an excuse to play with the state machine feature, so now I have it. 🙂