Fork me on GitHub

Released Fulcro 3.1.12 with official support for “floating roots”. See the docstrings in the new ns for instructions. and the updated demo is at: @mdhaney I’d be curious to know if the plain react root generator works for the js lib you are trying to use.


That looks like it could work a lot better than how I’m trying to do it. I’ll give it a shot and let you know!


oh, I forgot to do initial state 😕 @mdhaney be sure to look at the sample code…the hack of merging all root queries and initial state into the “real root” is necessary at the moment. I’ll fix it so it keeps track of which roots have been initialized in the next release.


but would be interested in hearing how it works with the js lib you’re using to see if other tweaks are needed.


@tony.kay OK, so in order to try this out, I upgraded Fulcro (was on 3.1.1). I tried to do that a few weeks ago and had problems with inspect, so I just stayed on 3.1.1 for the time being. After upgrading again, I still have problems with inspect - basically the Transactions and Network tabs aren’t working during app startup. Once the app is running, I can switch to the Network tab and do a refresh and see new network requests (most of the time - sometimes it just switches back to the DB tab on its own). But I lose the history of everything that happened during app startup, i.e. initially loading data from the server as the user automatically logs in. Have you seen this, or is there something I configured wrong? (I followed the configuration in the native template, because it looks like it changed for native).


OK, first: 3.1.13-SNAPSHOT might be better, as it handles initial state. Inspect: not sure about that…you’re putting the websocket-preload into preloads, right?


I’ve not noticed the problem…oh wait, there was an upgrade to Sente in there


You have to upgrade inspect electron client in order to use the latest versions


and then are you using websockets in your project? It might be sensitive to sente version


you want the latest of that, and then hopefully it will work 🙂


Yes, I did the preload. I’m not using WS in my project anymore, but I think Sente is being pulled in by some other library. I’ll check and if so, I’ll explicitly depend on the latest version, just to make sure.


Hmm, it’s the latest version getting pulled in. Oh well, other than that the upgrade seems to be working OK, so I’ll give the new floating root stuff a shot.

Ahmed Hassan07:02:37

What date and time picker you use with fulcro semantic ui?


I’m using react-datepickerbut it has some issues


I’m eventually probably going to fork it because it’s the closest to what I need that I’ve found

Ahmed Hassan18:02:29

Which issues are you facing?


nowadays i just use the HTML5 date(time) picker


it’s not the prettiest datepicker but it just works


and with semantic ui’s input classes it doesn’t look terrible

Ahmed Hassan18:02:25

@U09FEH8GN Thanks, what about time picker?


it’s all there


and mobile friendly


the main issues I have with react-datepicker are {:style {:width ...}} type styles don’t work, there’s no keyboard nav for times like there is for dates, and it’s impossible to delete (no onChange with a null value).


@U09FEH8GN have you been happy with the implementation on the various browsers?


happy enough


IE was a little annoying but if someone is using IE they have all kinds of issues anyway


but all the major browsers have been fine


it looks better than I remember


well this is with semantic ui CSS


if this isn’t in rad, we will probably be adding it very soon


Tony’s porting parts of our app to RAD


but in general i feel the web platform has finally matured and standardized to the point where i tend to check if problem X is solved by the platform before adding yet another JS dep


I've been trying out fulcro-rad for a bit. I was able to copy the code from the datomic adapter and adapt it to datomic cloud. A couple (5/6?) of adjustments and I was able to generate automatic-schema generate resolvers and use defsc-form for a simple user form. Great!

👍 4

Now I want to make a form with a recursive to-many attribute. :organisation/sub-organisations I think the schema/resolvers for that already work. But not yet with the form generation. Looks like when generating the query the class is not defined yet so it can't get-query on the subform. I tried to hack my way through by adding the query for subforms somewhat manually. But that doesn't work, I guess for that to work the subform generation needs to hook into the '... mechanism that fulcro has.


Yeah, isn’t supported by RAD yet. That one’s not high on the list of TODO yet either. You’re welcome to give it a go, but it is likely to be tricky. Creating a “new” thing in that relation is a bit tricky too (sibling or child?).


*why do you have to add a :target to specify the ident to update? shouldn't updating an entity in database be enough to cause all consumers to update?


i.e. the counter example in docs #(df/load! this [::counter-id 1] Countdown {:target [:counter]})


so the load will add an entity to the db


and the target will place it’s ident at the specified location, :counter


if the ident already is there then the target is a no-op


it’s not about updating UI, it’s about state modification


load an employee record, and put it’s ident at the path of the currently opened tab, that sort of thing


does that make sense?


yes, it does, ty. though I'm still wondering, fulcro has access to all components that composed :counter-id so why not have those components update automatically? seems like I'm still responsible for ensuring component data is not stale, whereas I thought part of the benefit of the normalization layer is that I'd be handled for me


i’m not sure what you mean, if the ident is already in the correct place, you don’t need target


fulcro will make sure all UI that renders that entity will update (indeed the benefit of a normalized data store)


the target is just syntactic sugar for adding a reference to a normalized entity somewhere else in your state


you don’t have to use it (if the reference (i.e. ident) is already there)


ah, ok, I understand better now, ty 🙌


so playing around w it more, I have a simpler example of what I was talking about say I have a component Foo with this query: {:query [:items [:item/id :item/label]]} my pathom resolver has its exact ouput, i.e. {::pc/output [{:items [:item/id :item/doc]}]} so the db/parser already has necessary data... but it doesn't show up in my app until I manually load it. (df/load! @spa :items Foo) i figured if it's already returned by my resolver and I added in my component's :query metadata, that's enough to indicate I want the data loaded into the component. so I'm trying to make sense of why it doesn't work that way... I'm coming from apollo graphql, where anything I query for in a component I'd automatically receive. I understand there could be more advanced case where the explicitness is necessary, but this is a simple query already being resolved by my database


i was bitten by this recently


also bitten by this a long time ago, sometimes still wish I it works like proposed. Wonder if this will get accepted!


thanks for the affirmation. The whole thing felt like an exercise in futility to write up, but I just felt a need to express it none the less.


There’s an entry for discussion here in case you’d like to add your opinion:


@tony.kay I’m having a problem where on startup, comp/*app* isn’t bound, so when I try to register the root, I get an error:


"Register-root cannot find app in *app*. You need with-parent-context?"


you’re using the react-class one?


Yes. This is with your demo app. I started out just dropping it in (converting the DOM stuff to RN controls) to make sure everything works and that I was understanding it. But I get that error when I start up. If I change code and do a hot refresh, everything works as expected. So there’s some problem with the startup order.


@tony.kay So why not just have the caller pass the app into register-root?


Wrapping the register-root call in with-parent-context fixes it, just seems weird to have to do that.


@mdhaney you pass the app to the function that makes a vanilla react class…thats the one I mean


so, the app is there when you use the class, and the internal factory that the generated vanilla class uses should be binding those dyn vars


Right, but in register-root, the first thing it does is check for those bindings and they are not set for some reason. I see the factory is using with-app-context like you said, but wouldn’t that only apply during rendering? Because we register the root during componentDidMount , so those bindings wouldn’t still be in effect, would they?


hm…there has to be something else going on…the lifecycle methods are getting called outside of the context somehow, but I don’t understand why.