@gardnervickers @wilkerlucio @mitchelkuijpers Beta10-SNAPSHOT (on clojars) has an upgraded env for post mutations and fallback. It now includes all of the original env (you can pass env instead of state for the *-action variants now), and the :load-request description itself. I think that’s pretty much all the information there is to know, including :component and :reconciler. I decided that you can decide when it is best to avoid using the reconciler and component in post mutations, and went ahead and included them. Worst case is you cause yourself an infinite loop, but you’ll figure it out 🙂

I’m going to update the documentation. The API is 100% bw compatible, it just doesn’t have as complete an env if you pass state to the action variants.

@tony.kay awesome!!! 😄

I’ve tested out load and load-action. I’ve not explicitly tested the field variants

Awesome :)

hello everyone

I’m working on an om-next based SPA

and would like to try to rebase it on fulcro

but I’m not sure if I’m going to fight the framework

because my backend is REST 😞

and I tweaked a little the send functions to parse the query that om-next would send to the server, converting them in REST api calls

is it a good idea to try to rebase my project on Fulcro? Or I will not be able to use the same trick of converting queries client side to REST api calls?

sorry for my english

the current version of my running app is there: https://193.204.199.198/

how does routing work anyway? I mean I never understood how one can modify query tree, since the query tree is static? How do you avoid pulling data for every screen in the app?

@rastandy you use the exact same technique with Fulcro

@roklenarcic unions and dynamic queries. Unions allow you to query just the active path of your ui. They are critical for avoiding exactly that: slow ui due to querying things that are not visible. See the older Untangled in the Large video on HTML 5 routing for some internal detail. This is codified in the library in routing namespace

Dynamic queries are just that: queries you can change manually on the fly. See the dynamic routing in that same namespace

@tony.kay so I can swap out the server side of Fulcro

@tony.kay by the way I’m watching the Fulcro videos on Youtube

@tony.kay thank you very much for such a great work!

@tony.kay I needed just a positive answer so I know I will not fight the framework and I can go and invest time learning it

@tony.kay I just started to take a look at documentation and videos

@rastandy Yes but it’ll be awkward if you’re not using Clojure/Clojurescript imo

You’ll have to reimplement the Om.next parser for the most part and your lang needs to support transit

@rastandy You do not have to use Fulcro’s server. You lose a lot of the benefits of data-driven development when you use REST, so for greenfield development I strongly encourage people, as @gardnervickers said, to use the full-stack system as designed (of Om Next…Fulcro just adopts it). If you have to have REST APIs for legacy reasons (e.g. 3rd party API users), then fine. Leave those there, but don’t use them for your own SPA. It sounds like more work, but in the long run it saves you a lot of headaches. Data-driven architectures are a response to the insanity of REST, not an adaptation on top of it. All that said, the clean model in the resulting SPA is nice, and if your network interaction though REST is tolerable to you, then there is nothing stopping you. There is an example of REST networking in the Getting Started doc.

So, I have a RFC. Anyone that has been using Fulcro (or Untangled) for some time: I’d be interested in your thoughts on error handling. I feel that this is an area that could use improvements, and the following open issue is where I’m tracking ideas: https://github.com/fulcrologic/fulcro/issues/28 My personal opinion of fallbacks is that they aren’t ideal (you don’t want to code one for every possible remote transaction, and they pollute the UI with full-stack concerns that should not be there). A global error handler is perhaps more practical, but is hard to make meaningful. I’m open to any radical idea anyone might have. At the moment, we all seem to be “making due” with the facilities at hand. Perhaps there is nothing central I can add to the library that will help, but it is on my TODO list to explore this more for beta10.

Technically that issue is around dynamic code loading with dynamic routing, but error handling seems like something that needs a better story in general.

I just had a discussion with David Nolen. The basic results of that are posted in this comment: https://github.com/fulcrologic/fulcro/issues/28#issuecomment-327629160