Consider Fulcro while project is young about athens HOT 16 CLOSED

The value proposition of Fulcro

I can try to elaborate on this a little. I have transferred to Fulcro 3 months ago (motivated by the pain of our Redux JS code) and have built one prod app with it so I am no expert - on the other hand, perhaps I can still see it somewhat "from the outside." Unfortunately I cannot directly compare the respective tradeoffs and consequences of Fulcro vs. Reagent since it is a while since I have used Reagent. It also doesn't really make sense to compare Fulcro and Reagent because Reagent (and excuse all my misconceptions, it has been a while, as mentioned) concerns itself primarily with the view and local state while Fulcro is a full-stack solution. @aisamu hints at what the difference means.

The two big things are (David Nolen's talk on Om Next provides the motivation and background for both):

(1) Graph API

You already understand and appreciate the value proposition of Pathom/GraphQL so I won't go into that more than saying that all the data for a page is fetched in one request and the page decides exactly what (tree of) data it wants. For those interested, Wilker Lucio's talk Scaling Full-Stack Applications is a good motivator.

(2) Co-location

With Fulcro you define the data needs of a component directly on the component (as its query), next to the place where the data is used. That makes perfect sense to me - when I need to change the one, I typically also need to change the other. Having those separate makes for harder maintenance.

The other facets

DRY: Data normalization

The Graph API delivers a tree of data and the components make up a tree of UI components (likely a super-tree of the data tree). But Fulcro mediates between the two and stores the data in a normalized, simple form. So when a piece of data changes (on the client or server), all places that use it see the new value. Again, less maintenance headaches.

Built-in data loading

How do you get data from the server into you components? With Fulcro, leveraging the defined queries, there is a single solution - the load! function. And it has built-in status tracking (loading?, failed?, finished). You can load the whole data tree or decide to load parts of it on-demand or load parts in parallel - it is all there for you. The only thing you need to do is to declare what data your component needs and write the Pathom resolver(s) that can provide the data. Actually loading the data, getting it into the state where it belongs, getting it into your component - is taken care of.

& more

State machines for complex user interactions, form support (with undo and diffing to make persisting the changes trivial), ... .

Is it suitable for Athens?

I have no idea. I don't know enough about it to be able to judge that.

from athens.

@aisamu Anything particular you want to share?

That was just a silly reference to one of Rich Hickey's talks 😄: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md

I believe Reagent is easier to work with.

I agree with you, specially for small projects. What the OP is implying is that this project's scope and complexity might warrant Fulcro's harder, but potentially simpler model.

I don't really understand the proposition of Fulcro. Many simple things become hard (e.g. forms).

The simple things become "hard" because there's a lot more being handled for you out of the box. (but I agree that it'd be nice to opt out of some of those)

I haven't used Fulcro in anger, but I've lived through more than one reagent/re-frame project that ended up implementing a lot of things that come out of the box with Fulcro (i.e. db normalisation, state machines, etc).

A very recent reagent/re-frame example: a non-trivial multi-step form involved manual db normalisation (we could have plugged something like https://github.com/den1k/subgraph), a lib to handle forms (using a fork of https://github.com/luciodale/fork), and a lib to handle the business logic "state machine" (https://github.com/day8/re-frame-async-flow-fx).

Again, reagent is just fine for simple things (even without re-frame), but as new features are piled sometimes I wonder how things would have been if we had started from a more principled/formalised model.

I can't claim that using Fulcro would have been better, but this statement is what worried me:

I don't really understand the proposition of Fulcro. Many simple things become hard (e.g. forms). I haven't experienced the power of Fulcro and others haven't been able to show me.

While I haven't experienced the power of the full package, I can guarantee you that I've had "a-ha" moments for many of its constituent parts/features (that we ended up reimplementing on re-frame anyway).

Regarding the built-in data syncing, I'm not sure if the Fulco model covers all the potential "syncing" scenarios of Athens.

Do you mind elaborating on that? (So that we can request some input from experienced Fulcro devs)

from athens.

I'm a new Fulcro user that has evaluated Reagent + Reframe + Fulcro. So I thought my opinions and thoughts could bring some value.

Not considering any specific use case and only speaking generally, I think Fulcro is a lot harder than Reagent, but it is because Fulcro can do a lot more than Reagent can. Individual concepts are quite small and, for me at least, easy to learn. I'd argue that if you know the ins and outs of both, you get more leverage having chosen Fulcro as the complexity of your application bloats. Also, if you really need ease, you can just opt out of using more advanced Fulcro features (form state, dynamic routing, ui state machines) and stick to the basics (stateful component, mutation, load, transact). Eventually you might notice that not using the advanced features make your code more complex, you learn the new concepts and make your code simpler.

With great leverage comes great learning curve.

from athens.

I believe Reagent is easier to work with. I don't really understand the proposition of Fulcro. Many simple things become hard (e.g. forms). I haven't experienced the power of Fulcro and others haven't been able to show me. In contrast, Reagent's power is pretty clear to me.

Regarding the built-in data syncing, I'm not sure if the Fulco model covers all the potential "syncing" scenarios of Athens.

I am a fan of Pathom though. Luckily this is available as a library.

If you are an experienced Fulcro developer, you might be able to convince people here by creating some examples.

from athens.

from athens.

@aisamu Anything particular you want to share?

from athens.

I've started on my personal database for now: https://roamresearch.com/#/app/careplanner/page/K9cRNsm9G

It'll be loosely based on https://youtu.be/wEjNWUMCX78 and follow up videos but hopefully easier to skip through since it's text and it's more about learning the related things than quickest to market since there are Fulcro templates out there to skip all of this

edit:
First page: https://roamresearch.com/#/app/careplanner/page/_DHXtNGVq
Second page: https://roamresearch.com/#/app/careplanner/page/kaByyteky

There's also a video of me working through page one with a friend, but it's low quality and not publically available, pm if interested

from athens.

One thing that sticks out to me about Fulcro is that it more natively supports datascript. I've noticed a few quirks since using re-frame and re-posh together. One is that re-frame-10x doesn't work as well as I'd like it to with datascript queries. Does anyone have experience with Fulcro Inspect + Datascript?

from athens.

I believe Reagent is easier to work with

:disapproving_rich:

from athens.

Thanks all for input. We don't have any experienced Fulcro people in the group. In fact, many are Clojure first timers. It will probably be easier for them to get started with Clojure, Reagent, and re-frame. Fulcro seems like a great solution at scale with a little more Clojurescript experience. Hope we can get to the point where we need it!

from athens.

I'm planning to make some beginner docs for Fulcro in Roam, because honestly a lot of Clojurians are in a similar position right now, it's easy to recognise the value of Fulcro, it's hard to get started, there are so many linked concepts it's intimidating

from athens.

Beginner docs could be helpful! To me, the Fulcro docs are really, really intimidating. Reminds me of kubernetes docs.

When there's that much content, I think it helps to use spatial software like maps or mindmaps like in Onboarding for New Clojurians. This helps me think about the space at the right level of abstraction.

edit: the re-frame docs also take a while to digest. And we are considering something like pathom, especially since Athens will one day be pulling in multiple data sources.

from athens.

@slifin don't really know much about fulcro but I'm very interested in it's value proposition. Would be up to collaborate on the doc if you need an extra pair of hands.

from athens.

hey @jorda0mega thanks, my main blocker at the moment is I can't get hold of another Roam database, I started writing some in markdown but then quickly realised I need a networked platform to link everything together properly

I also help organise Bristol's (UK) Clojure meetup, on Wednesday we will be trying to do our first recorded meetup, and the topic is "hello world" in Fulcro, this will be here: https://www.meetup.com/Bristol-Clojurians/events/zdfnqrybchbbc/ Hopefully we can start producing some useful video artefacts out of that too

but yeah if anyone can get me a URL like https://roamresearch.com/#/app/fulcro-tutorial I would be very grateful

from athens.

@slifin very cool idea about the meetup, if it is recorded I would love to watch. If roam is becoming a limitation I can also create a notion page to collaborate on and invite you with write permissions. If the team finds it useful then they can simply clone into their onboarding page.

from athens.

May re-open later

from athens.