Clojurians Log v2

Wait with that… 😅

Let me know if you want help or to pair a bit

I’m interesting in contributing. Could I join if possible? I’ll have some time later this afternoon (central time)

Let’s see what @holyjak says…time zone coordination can be hard, but I might be able to do that. Today is going to be a good weather day, so I might opt to be outside instead. But yes, you’d be welcome, of course! We just need to coordinate. You two are free to pair up. In general we use Tuple for pairing (which @holyjak actually turned me onto). You don’t need a license for it, as both of us have a license and we can invite guests.

I'm sorry, I can't today

Tomorrow though may be possible, around 8-10pm UTC...

yeah, that’s 1pm my time. I can do that.

Awesome! I have sent you a calendar event. @yaw556, send me your email if you want to join. I’ve stopped paying for Tuple, so if you still have it, you’d need to invite me as a guest 🙏

Yes, I have a OSS tuple license. You both can PM me the tuple email address

Perfect. I should be able to join 🤞🏿

I am certainly on that dark design path. Keeping the entity id (selected account id or profile id) in the app state and out of the URL path would be cleaner. However, it limits deep linking. I have an account router with child components that query on a specified account id for data related to the account. What’s a good pattern for initializing the fulcro app state with or without an account id in hand? • local storage - seed the app state with the id from local storage • route param (`?rp`) - this was the path I was on. But the params are reset when navigating between screens. Thus requiring me to set the account id each time I call route-to!. I suppose the main account route component could set the id in the app state on will enter, allowing child route components to query it as needed. As a fallback, redirect to accounts list route if the account id is not present in the route param or app state. Would you put that logic in the will-enter?

If you really want deep linking from URLs where a page can be bookmarked then you have no choice but to include it in the URL, of course, and using the route params seems a reasonable course. You have a number of options, but since it is a global concern, I would tend to place that code in some global wrapper, and not in each component. E.g. you could make a URL that always has the account ID in it, but DOESN’T go to Fulcro’s dynamic routing code. I.e. you split the URL, drop the account ID (but put it in app state at the right place) and then send the rest of the URL to route-to! (this would be on startup from a URL) and you make your own HTML5 history plugin that always writes the URLs with the account id from state into the URL, etc. Basically try to model this concern globally. There’s nothing in DR that says you have to even use a URL with it, so writing your own outer layer for interfacing with the URL itself for tracking some important app state is where I’d put it.

In other words: I’m not claiming that dynamic routing is a fix-all for every use-case. The mere idea, as I’ve said, that routing should be so tightly coupled with your UI has never set well with me, but many many people like doing it that way. YMMV. I’m more and more leaning towards writing a state chart, and having it do routing based on enter/leave states. Then the global application logic can be properly modeled and not peppered into the UI so much. I’ve been toying with co-locating invocable state charts on components, and using a global state chart as the overall routing tool in my own work, but I’ve not gotten it refined enough to release as a library or template.

Ah, sorry, I completely forgot about this 😢

I may give up on porting it to F3…if you wanted to take a shot at porting just the background job, I did find some tips for that…any interest in that? The first tip I found was this: https://github.com/thheller/chrome-ext-v3 and I think all that needs to happen is to change the shadow build config, fix up the manifest, and rewrite the background job to work as a service worker…not sure what kind of code changes are needed there.

but hopefully just a few on the chrome wrappings

That would not be very good composition for a child to be dependent on a parent. Also remember that routing is often done in a relative manner, and there may be NO URL (e.g. in a mobile native app). Thus, what you are really after is application state that remembers you’re in some sub-section of your application. Dynamic routing is not intended to solve this use-case for you, and the URL integration should be thought of as an “external” concern that is orthogonal (but somewhat compatible) with the routing system (which is more about dynamic query management and UI targeting). What you need to do is find a place in your app state where you store the “current profile” as a fact of the current application state, and then query for that in any component that needs it. This also has the advantage of not requiring the parent to be involved, and improves compositional behavior. This means you need to define a clear lifecycle around that fact (when does it get set, when does it get cleared, etc.). Thus, defining a UI State Machine or State Chart for that part of your application (and getting this logic OUT of the view layer) would be my recommendation. I was always a bit resistant to even adding the dynamic routing features as they exist (the will enter hooks etc) because they sort of encourage this kind of bad composition, but are also quite convenient for many other things. So, I’ve leaned on the side of convenience in those APIs, but it does lead people (including me) down some dark design paths.

Thanks for the offer. I ended a few hours of work on it last night, most of which was just porting old code to new versions. I think the primary thing is switching the background job to a service worker. But I think I found an example of that

FYI I am in the meeting, hope joining works…

Still wait on my tuple email confirmation...

What kind of confirmation? Were you not able to finish setting up your account or what? Anything I can do?

Almost got it

I had to go, my WIP PR is https://github.com/fulcrologic/fulcro-inspect/pull/104 Replacing the unsupported and discouraged whitespace w/ simple got rid of the goog problems, now it is Fulcro failing with > Uncaught #error {:message “Invalid join, {:fulcro.inspect.ui.inspector/element nil}“, :data {:type :error/invalid-join}}

Perfect! I think that may get it to the point that I can finish the port.

thanks! I’ll see if I can get back to it sometime later today

It is confusing to have 2 threads of communication, I suggest we move to the DM group chat.

I can try to make some time during the week and give it a shot…

thanks!

I went the state machine route....way better. Cheers! thanks3 Would be nice to get something like https://statecharts.io/inspect in the fulcro inspect someday.

I would agree.

aaannnnd you just reminded me that I need to fix inspect in the chrome store or they’re going to stop allowing it to work 😞

Ha! Let me know if I can help out with that. I am not extremely familiar with Chrome extension dev nowadays, but I could brush up on things.