Fork me on GitHub

2.0.0-RC4 on clojars. This should be the last RC. If I don’t get any bug reports this exact version will turn into 2.0. I want to do that relatively soon, because I have a number of things I’d like to start bringing in for the next cycle.


The major improvement on RC4 is that I got rid of the compiler hack I inherited from Om Next! No more weird build profiles to get the things to compile in advanced mode.


Upcoming things that I’ve finished, but not merged just yet: - Eliminated the need for :ui/react-key (which caused components to lose local state) - Added new rendering modes: :normal, :keyframe, and :brutal. The middle one can possibly be used by many apps to eliminate the need for follow-on reads. Basically, the first is hyper-optimized, the middle is pretty optimized, and that latter is not optimized at all….that last one is more for benchmarking differences than anything else. - Added support for -DrawInputs on JVM opts. This causes form elements to be raw React elements instead of the souped-up wrapped ones. Should actually work better, but it is opt-in for now. (the -D means define to the JVM, the value is rawInputs). I realize it reads like “draw inputs”


I read the new getting started guide yesterday. It was really good 🙂 Maybe the only thing that came to mind was that it'd be nice to show how you show an indicator while a server request is underway, and show the results when they return. That's not immediately obvious to me.


There’s all sorts of stuff the getting started doesn’t show. The demos and dev guide cover loading markers


I guess you'd just set :loading true in the mutation, and to false in the :post-mutation?


Fulcro has built-in loading markers


legacy mode and new mode


You need the internal help, because you could have multiple remotes, and various things that are loading can therefore finish at different times. You don’t want that async stuff in your UI 🙂


I’m working on getting everything from the dev guide into a book form (html/pdf) so it is easier to search


that’s the biggest problem with the docs right now: hard to search


Hmm, I'm wondering whether I understand the "only the global activity marker is available for mutations" correctly. If I have a "save"-button, I have to use optimistic updates? I can't show an indicator that a server request is underway? I get the point about optimistic updates, and I've kind of been feeling that non-optimistic(?) updates are kind of an anti-pattern, but this feels a bit too limiting, if I'm correct.


Say I want the button to send a request to insert/update a record, and then the same request should return the new list of things. I guess this isn't how you're supposed to use fulcro?


I guess not, since I'm mixing mutations and loads in that case


@kauko we were having a discussion just about that in #pathom recently, there are some example codes on how to make pessimistic transactions (with load indicators) over there


That demos does exactly what you’re talking about. The optimistic part is optional on any mutation…and it can do things unrelated to the network activity. The “I want to wait until the server responds” pattern is trivial to do with ptransact in 2.0


@wilkerlucio You might also look at that demo. I think what you’re suggesting on the pathom channel might be trying to do this, but I don’t think you need new macros around it.


thanks, I had saw that before. The macro is just a facilitation, because if you want the local db changes to happen only after the remote mutation, then you have to create 2 mutations, the macro just helps with that.


@wilkerlucio When using Fulcro Inspect there is usually one 'host' application, and there might be other tools. Both these types of apps will be target apps, inspect-able by Fulcro Inspect. When bringing up Inspect (via the configured keystroke) the developer probably wants the default "App" to be the 'host' application, rather than some other tool. At the moment the only concept is targets that have app ids that are sorted by app-id, which is the name of the root component of each target app. Can I open an issue for this? I think there should be a way for other tools to co-exist with Fulcro Inspect, without being the first target that the user gets to see the client state of. (Of course there's a work-around, but it involves another tool's namespace starting with 'zzz' - maybe slightly different sorting would be enough of a change - sorting by the name not including the path).


@cjmurphy Is this a real issue now, or a perceived future problem?


we’ve all got a lot going on, so feature creep should just be kept at bay 😉


It's a real issue because I'm doing a tool myself. I was just trying to be a bit abstract about it. At the end of the day a slight change to the sorting would work for me. Hardly anything that is what you call a 'feature'. The sorting is currently: app-id (->> (map (comp pr-str second) inspectors) sort). I was asking about opening an issue so this could be discussed there.


Actually I don't think that the sort order has anything to do with what is the 'first picked app id'. I might raise this again when everyone is less busy and I know how to fix the problem - which is one of potential annoyance and confusion for users.


@cjmurphy what about that: for what you are saying, the problem is that on refreshes on lose the target on the actual app, and have to switch. in case that's the problem, I think we can "remember" the last used app and focus on it on load, would that solve this issue for you?


There doesn't seem to be much point on including the path part in the sort anyway - sorting by the name of the root component seems reasonable.