Fork me on GitHub

@tony.kay the fulcro.client.routing/current-route is nil from my :integration-router, that’s the problem


before the :fulcro.inspect.core/app-uuid is populated as well :thinking_face:


just a guess @pvillegas12 but are you using a load with a marker on those routes?


or perhaps you’re missing initial state on one of the components


2.6.2 is on Clojars. Fixed the error messages a bit more: Now the location of the error is reported more accurately.


not using a load marker


@tony.kay looking over (which I used as reference) the index loading behavior exists as well when reloading in a url such as /reports/2, the INDEX HOME flickers after routing there.


@pvillegas12 I have noticed flicker with a targeted df/load. My assumption is that the :target ident (just one in my case) gets removed and replaced every time. To remedy this I did the df/load but without a :target. Instead the target ident is setup at application startup. At the end of the day there should be no flicker when state you already have comes back down the wire again, as you are say going from one tab to another.


Perhaps this can be remedied with a load marker?


I'm not using any load markers at the moment, and am happy with the remedy I described. If anything I would look to load markers as being a 'cause of', rather than than a 'remedy for', flicker.


@pvillegas12 I can tell you that if you see a flicker then the state is doing what you are seeing. I don’t have time to rewatch the video, so if you want to reference that, you’ll need to given a timestamp where you see the behavior you’re talking about. The videos are about concepts, so it would not surprise me to see a bug in any of them.


22:48 @tony.kay Yeah, the videos are great btw, excellent resources


22:40 and you’ll see the flicker I’m referring to


Ah that…ok, so that is because the app comes in, the initial state says “index”, it renders, and then the pushy install sees the URI and triggers the route event.


@pvillegas12 That really isn’t anything wrong, per se…the way you work around it is to put a “ready” marker in state that defaults to false. Render a loading thing if ready is false, and have a mutation that sets ready to true once the app has finished starting.


If you use server-side rendering, then the server would need to send the correct screen along with alternate initial state. It really isn’t anything special: you just have to realize that the startup sequence is fixed: Start gets initial state, runs the started callback, and renders. But some startup things cause async events that are going to ask to update state very soon thereafter (e.g. loads or a history event precipitated by installing a history event system).


So, you’re seeing a render of initial state, and then a short time later the event is coming from the install of a history event handler which updates the state. If you don’t want the flicker, just make sure initial state doesn’t allow a real screen to render until you’re actually ready.

👍 4