@tony.kay In beta-2 there was a function ...dynamic-routing/initialize!. In beta-3 you removed it but didn't mention it in the changelog. Is this function obsolete or what happened?

@mroerni to be honest I don’t remember 😜 It wasn’t documented, I don’t remember writing it, and it didn’t even look like it did the “right thing”. The routers initialize themselves on the first change-route.

was probably something I started to write, got sidetracked, and forgot to go back to.

re-added in beta-9

I think the idea was that an initial change route initializes the routers affected, but initialize will get them all…I think there’s some corner case where you want them all initialized at app start. Thanks for finding the usage I’d created @mroerni, it makes me think I did actually find a real need. Should add it to the docs, too. Beta-9 is on clojars

dynamic routers have still not been exercised heavily in all respects. We use them in various projects, but the deferred routing isn’t something I’ve heavily used, and there are cases where app state might need a bit more tweaking for “deep routes”. The router definitions start out with everything in the query and initial state, so initial state should be right.

com.fulcrologic/fulcro 3.x will include "legacy" fulcro.client* ns's? com.fulcrologic/fulcro 3.0.0-beta-6 include fulcro.client* com.fulcrologic/fulcro 3.0.0-beta-9 *don't* include fulcro.client* I can't find any relevant change in git commits.

no

@souenzzo that was an accident of jar creation

Hi, newby here. How different is Fulcro 3 from 2 (I saw there are videos on Fulcro 2, thats why I am asking)?

There’s pretty detailed guide here: https://github.com/fulcrologic/fulcro/blob/develop/PORTING-FROM-2.x.adoc If you’re just getting into it, personally I’d say that it makes more sense to go to 3. The videos are quite good, but obviously out of date in some places. You could potentially go through them (“Understanding Fulcro” in particular) with the porting guide by your side. All the basic concepts more or less apply, but a lot of the improvements in 3 are for ease of use/comprehension/etc

I’ve delisted the videos (they are accessible if you still have the links) and plan to record more soon. The porting guide is a bit incomplete, but all of the critical stuff is up-to-date in the new book (linked at this channel’s topic)

most of the porting tasks are mechanical in nature…lots of namespace movement of functions. A few things changed signatures, and some of the internal data-passing changed format. Summary of the “big” porting tasks: - There is no reconciler now: use app everywhere - The remotes no longer use protocols, and are just maps. If you used standard networking, there are replacement construction functions. - server-side: only middleware and config was continued. handle-api-request signature changed. - defsc: React lifecycle methods are no longer “special”…you must add this as explicit param to all of them that are not static. - No defui, ui macros - No more protocols involved in the main lib. This means defsc :protocols was discontinued. This makes it more easily extensible. - UI state machines: return value of mutations changes - Incubator pessimistic mutations: adapted/adopted into Fulcro, but the data that is passed around has slightly diff format/keys/behavior. You can plug an alt implementation of mutation internals to change that if you wish. Can use regular comp/transact! (or ptransact!) to run them. - UI Refresh is pluggable, and works differently. Only rendering “derived” data (e.g. a parent rendering a count) has to inform Fulcro of extra refresh

During Beta I’m trying not to change any names or move anything else…but I may not be able to honor that in the cases where something got missed. Mostly that could affect internal keyword names that should not matter externally. I’ll include such changes in the CHANGELOG if I feel they are important and not likely to be hard to deal with.

does anyone use workspaces for visual regression? I’d used devcards for it in the past, they’re simpler for that particular usecase, but of course workspaces have all the goodness.

Thanks for the answers!