I'm working through the dev guide, yet when I connect to the nrepl and try to execute (require '[user :refer [start-figwheel]]) I am getting a file not found exception, is there something that I am missing?

@joshua.d.horwitz hm…something seems amiss

oh shoot

the directions assume figwheel is the default, which it isn’t anymore

I need to update the guide

That’s not so good. That’s actually a big change to the docs I totally missed. Seems I should probably revert the template to figwheel for now

Thanks!

I’ve release an update to the template on clojars. If you regenerate your template according to the instructions, it should work now. I’ll leave figwheel the default until I have time to rework all of the docs.

thanks for reporting it. that was a big oversight on my part

@tony.kay I was expecting there would be a way to merge into the normalized db like it seems to here: http://book.fulcrologic.com/#_adding_sub_form_elements :append [:thing/by-id id :attribute/list] My app state thus-far is there because of a load which works well (three levels deep of entities get their data), but after my prim/app-state is tree-shaped. I would expect to transact/merge into a normalized db. Which is why I asked if it is expected to be not normalized after a load.

So, normalization is a function of the query. It should be normalized if you use a proper load and query

mutations have to normalize the data they add

integrate-ident! does not normalize things…it expects them to already be normalized

merge-component! is one way to use a component to supply a query for a merge

within a mutation, use prim/merge-component

the ! version would be used for, say, a websockets push

Okay, so I guess my load didn't go as it should, since the app-state after is not normalized.

what is your load?

and do your components have properly joined queries with idents?

and have you watched any of the YouTube series? 🙂

I have read the dev guide a lot. Watched a bit of the youtube series, maybe I'll study it more.

just making sure you knew about them 🙂

My load:

(load app ::model/processes Root
                                         {:target [:root/processes]
                                          :marker false})

(defquery-root ::model/processes
  (value [env params]
         (def env env)
         (:root/processes (prim/db->tree (:query env)
                                         @server-db
                                         @server-db))))

oof…Root?

not what you want 🙂

what kind of thing are ::model/processes

(defsc Root [this {:keys [:ui/react-key
                          :root/processes]}]
  {:query [:ui/react-key
           {:root/processes (prim/get-query Process)}]
   :initial-state {:root/processes []}}
  (dom/div #js {:key react-key
                :style #js {"margin" 10
                            "marginLeft" 65}}
           (map #(ui-process %) processes)))

you want Process

the rest looks reasonable

don’t need react-key anymore

Okay, I'll give it a shot with querying for Process. I thought the whole mantra of "query goes from root" applied.

So, loads load specific kinds of things. The “query composes to root” rule is a UI rule

Okay, that makes sense. I'll figure it out!

So, when you issue a load you want the query of the load to match the thing the server will return. If you’re returning a Process (or vector of Process) then you’re querying the server for Process

no mind bending around the root UI query.

Loads do have to load into somewhere, and they will load into the root node under the query property by default, so your :target is correct, but possibly not because you understood it correctly. Load loads the data into the root node at the “query property”, and then target will “pick it up and move it” somewhere else in the graph once it is there.

Okay, I'll mull that over 😄 Thanks again.

sure

One of the YouTube videos is an old white-board video where I go through the loading story

I’d recommend that one. It was back when it was called Untangled, so just translate the name 🙂

I think I watched that one at the time, probably didn't get it 😅

the video series also covers load in a detail

don’t sweat it. You’re actually making it harder than it is…but that’s typical with anything new/different 😜

too many ways things “could be”

I hope it's even simpler than the way it "should work" in my head haha!

And yes, many ways things could be, that was one of the problems I had with grepping om next. And the guide has given taken tons of gotchas away for me already.

If “how it works” helps (I know it does for me), load combines the keyword and query of the component into a join query:

(load app :k Comp) ; means to query the server for [{:k (prim/get-query Comp)}]

Oh, you studied Om Next…that’s actually a disadvantage for you 🙂

because in Om Next loads DO always go from the root, and you have process-roots, and a whole bunch of network layer translation

Fulcro doesn’t have any of that

it’s built-in and abstracted

Yes, it seems to require a lot less work so far. The parsing for example.

you say what you want, it gets normalized and dropped into your database, then you can pepper it into the graph with post mutations or targets

I'm gonna go and make it work! 😄

ok!

I think about 7 characters of typing will do it

:thinking_face:

Process

Yes! State is normalized and components got their data. Only thing besides changing the load to Process was to change the server response to change the query to [{:k (:query env)}]

@tony.kay when running lein test, I’m getting errors saying macro-create-element* can’t be found. I see that it’s defined as a function in .cljs. Is it possible that alpha.dom isn’t supported in the clj side?

I know that fulcro calls itself a library, but would people agree that it's more of a framework? I've wanted to try it several times, and always end up returning to om.next with a feeling of information overload. Despite om.next feeling slightly abandoned, it's fairly easy to understand it as a whole and know how it composes. The quick start is just great imo (https://github.com/omcljs/om/wiki/Quick-Start-(om.next)); that it doesn't use a lein template and you can get the basic idea in a few lines of code. Am I missing the trees for the fulcro forest, so to speak? It just feels like I have to read all of http://book.fulcrologic.com/ to understand everything the starter template is bootstrapping for me, and I'm yearning for a polished and maintained om-next (perhaps be more opinionated on the app-state structure) without all the distractions. Hope this doesn't read too much like a critique, because there is obviously a place for opinionated collections of libraries e.g. luminus. Just wanted to share what has prevented me from adopting fulcro (again, maybe it's just me).

To put another way: it's nice to know that fulcro has thought of everything, but I kind of want a lot of it out of my face in the beginning when i'm getting started.

@danielstockton Hmm, I've not been using fulcro for too long. But my 2 cents is that getting into fulcro has been paying off, I had tried to grok om.next, but its documentation gave me a bit of "rest of the fucking owl" feelings at times. I find that going through the admittedly big fulcro dev document has taught me to draw a much bigger part of the owl and I don't feel it's too opinionated: I recognize many problems I've run in to with web development have an obvious place to solve them cleanly with fulcro.

I did ask and get help from the man himself a bunch of times, but really I find it a better story so far.

Om.next is definitely a two circle owl (Nov 13, 2015 - Soon). I think the uneasiness that gives off is offset by the fact that I know the om.next codebase inside out and it feels like a solid base. However, fulcro feels like a very detailed owl. Hmm, do I like these ears? Can I remove this? Am I being sold an opinion here that will be hard to change later? It might be that it's a personal preference for 'start from the basics and build up' vs 'start with everything and see what I can get rid of'. Similarly, I like arch linux as my OS, because I want to start with nothing and install the packages I need, rather than have something that is catering for everyone but with a lot of bloat. It gives me a nasty 'there's something hiding in the corner' kind of feeling. At the same time, it's impossible to understand absolutely every level of a system...there's a balance somewhere.

I do think the fulcro docs are a bit overwhelming and there could be a gentler introduction, where some parts of it are discovered later in the journey.

I understand where you are coming from, I haven't found "it does too much" yet, and I think I've read most of the document. I was afraid it would be too detailed too, I already had a back-end and was initially using server-sent-events in stead of websockets. But that turned out not to work in the chrome extension I am building the cljs part in, so had to switch to websockets anyway, so fulcro choosing websockets there was no issue. Integrating fulcro on the server was not too difficult, some middleware and extend the "packer" with some transit handlers I need for sending literalbytestrings. But yeah still not used it too much so no veteran opinion here, making fast progress with my project though so that's good!

The fulcro-inspect doesn't seem to work in my chrome extension though! But that's not a blocker.

That's another good point. I also wanted to integrate with another backend, but the starter template creates both the front and backend parts in one project (i think?). There's a lot of upfront work to see how things can decompose.

I would use om.next happily, but I do worry i'll be the only one maintaining it in a few months. Perhaps that's not true, people are just quietly building great things 😛

I was already using aleph, and it that one had an adapter already (most big servers have an adapter). So plug that and some middleware with websockets.

Took me a couple of hours to figure out.

Another concern I have is that fulcro is too big to sustain itself. It's a compilation of lots of small libraries all made for this ecosystem, and that could easily fall apart. At least with om.next, I only worry about having to maintain that part.

This could be totally misguided... but it's the impression I have.

I wouldn't know about that.

Anyway, I think my essay boils down to 'gentler introduction' and 'don't try to do too much'. I could easily be lured in, if it was presented more like a collection of optional, distinct libraries.

Personally would not put fulcro in the "framework" category. You get a lot out of the box but most it's not limiting you, or at least for me it hasn't. After all you can just use it as a state management library just mutations & query reads, build your own network. Think you can actually hook in and just write read parses like in om-next for keys also.

Struggled a bit to "get it"... but afterwords felt kinda stupid since explaining most of it is really simple. Was quite a bit of upfront-work for me, but really was worth it, recovered the time really fast since afterwords the project dev was just gliding along 🙂

And om-next. Read parsers seem very fragile, no intitial-app-state, network layer in fulcro really saves me a lot of headaches. Also if somebody will join the team I can just point them to the exact places in the docs/videos, with om-next it's really hard to onboard people

For my projects I really need to keep the complexity as minimal as possible, Fulcro really delivers on this, but yep "there's a bigger initial learning step". Re-frame would be a lot easier to learn, but then would have a lot extra complexity to handle in the long run. My experience with om-next is that it's hard to learn and pretty hard to maintain.

"After all you can just use it as a state management library just mutations & query reads, build your own network." - I'd like to see more of this presented with much less noise. Since fulcro claims to be about 30% based on om.next, I'm not sure how it can be easier to learn. It's only easier if you're happy to ignore how certain things happen under the hood, which personally makes me a bit uncomfortable. It's nice to be able to treat some things as a black box, and concentrate on getting things done, but you want there to be clearly defined boundaries to the black box.

@danielstockton My experience is that you can start and be productive treating it as a blank box, but as you go through the docs/videos and fallow along on slack, it really starts to make a lot of sense, and you start learning a bit about the internals since it helps you get the most out of Fulcro.

Conceptually, for me the app is has: a) generate initial app state (can use initial-app state or just pass it the atom) b) queries to get data to components (can use the default reader and fallow it's convetions or just http://book.fulcrologic.com/#_using_a_completely_custom_parser) c) mutations to modify the data (like in om-next but here you also have ptransact! for loading states etc... if you want) d) load data from the server and put it into app state (you can use df/load, put it in actions or just add it yourself to the state)

@danielstockton There is a bit of learning since fulcro offers quite a bit. But compared to writing/documenting/maintaining this stuff yourself ? Networking, initial-state, defsc, co-located css, ptransact! etc... Seems like quite a lot of work to get this in om-next.

It's nice to have all that stuff, but it's also nice to know that you could write it yourself. Co-located css is a good example of something that could be a completely separate library: https://github.com/ladderlife/om-css I think the core could be distilled much further into the parts that actually make assumptions, and everything else discovered later, as patterns or separate libraries.

Think it is separate. The one from ladderlife i do not really like since it seems to only generate 1 huge css file :( fulcro css just composes and i can just have the css in the module or page.

https://github.com/fulcrologic/fulcro-css

There are examples in the fulcro book that use timbre logging or internationalization, and these are in the getting started type examples. This doesn't help get across the core ideas of fulcro. It doesn't seem like there's anything preventing using fulcro-css with an om.next application, so again it seems like noise when trying to learn fulcro.

It's just overhead to decompose everything and work out what is and isn't wedded to the fulcro core

Anyway, i don't want to keep repeating the same thing over and over. I'm just one data point and clearly you and others were able to find your way inside to where you feel comfortable.

@tony.kay @thheller I know you did some changes to the advanced compilation stuff a while ago. But we notice that prim/shared is not working anymore. Any idea if it might be related to that?

what is prim/shared?

http://book.fulcrologic.com/#SharedState

Hmm maybe we did something wrong not sure yet

I am losing shared somewhere and it's only with advanced compilation

@mitchelkuijpers does it work when you set :js-options {:optimizations :whitespace} in your build config? if yes its a problem on the closure side of things.

it will only affect the imported JS. the rest is still done as :advanced

@thheller Thank you for the tip, with these optimizations it still loses shared, but on a dev compile shared does not dissapear

New alpha dom combined with map instead of mapv makes it lose the shared state..

Thank you for your help @thheller i could at lease re-test with simple optimizations in 7 seconds instead of 60 😛

ah ... the dev version of react checks everything when React.createElement is called. this would force the lazy-seq of map. this is not done in the react production version.

so it probably expands at the wrong time. makes sense if mapv fixed it

@danielstockton So, I share some of your surface opinions: Fulcro contains what could be split out into several libraries. When it was Untangled, it was exactly that: client, server, websockets, css, etc. The advantage was in PR: the Clojure community likes little pieces. The disadvantages are: - Tight integration is very difficult or impossible. I’m, in fact, integrating fulcro-css in the next version because it allows me to supply better DOM integration without circular library references. - However, many of the components are, in fact, completely optional. i18n is integrated, but you can choose your own. bootstrap3 is there for convenience, but is a standalone ns that could easily be it’s own library, etc., etc. - The reason most of these “optional” things are included is for my own convenience: It’s a pain in the ass to maintain 6 different libraries, with 6 different test suites, and 6 different releases, etc. We have Closure. It’ll strip out the stuff you don’t use. - I realize that having it all together makes entry seem a bit more overwhelming. That said, the real things I would hope you’re concerned about are having to understand things like “how loads and targeting works”. Again, the solution in Fulcro is intended to be general, but there are some compromises (not in terms of generality, but in terms of what Om Next was trying to allow). I’ve talked about those at length in many many places, so I’m not going to repeat them. I will mention that the most significant, customizing the client parser, is now completely doable, though I still don’t advise it.

If your complaint boils down to “the docs intimidate me”, I hear you…I keep trying to make them less so.

that said, I personally find the “tiny library” mentality a weakness and strength of the Clojure community. It’s also a weakness and strength of other communities like NPM. At its core Fuclro contains Om Next (3500 LOC), and then about 3500 of Fulcro-specific stuff stacked around it to supply the “missing pieces” (parser, plumbing, glue, loading story).

The rest of the code in Fulcro is completely optional and can be ignored if you don’t need it.

Also, you’d be very hard-pressed, I think, to come up with a general story for adding in the required missing pieces of Om Next in less code…but you’re welcome to try 🙂

It's a fair point about tight integration being difficult otherwise, and that's mainly why I didn't mean it as a criticism. As you said, there are advantages and disadvantages of both approaches. I suppose it does boil down to the fact that "the docs intimidate me" and I'm just looking for an easy way in. I do also worry that some of the missing pieces and plumbing are not necessary in all applications, but I understand that fulcro is aimed at fairly complex applications where most of it is. It would be great to have a gentler introduction that focuses more on core, and leaves the optional/advanced things to be discovered as required. Anyway, I hope the community can take on some of the work ("The reason most of these “optional” things are included is for my own convenience..."), because it seems like you're doing a great job of solving everyones problems and you probably deserve a holiday 😄

Did you try the YouTube videos? I personally find those easier in some senses

but yeah, perhaps I should re-work the getting started chapter of the book

@mitchelkuijpers sounds like we lost force-children on DOM…I’ll look at that. Can you confirm that shared isn’t working, or is it just DOM that isn’t working?

I didn't, mainly because I'm always short of time and looking to get straight to the point. Text can be easier to jump in and out of, without requiring a lengthy period of concentration. To be clear, I find the docs intimidating in the sense of volume + lack of focus, as opposed to the concepts. I feel like I understand the concepts and what fulcro wants to achieve pretty well, I just can't fit the whole system in my head and decide whats essential/optional/can be replaced. This adds a barrier to acceptance, because I feel like I have to buy into everything at once.

I try to keep the videos to 20 mins, and you can always watch them 2x speed. I hear you about the docs, though. Some editing would help. Perhaps even a separate doc that is minimal and gets you going, a cheat sheet that tells you what’s “required” and what’s optional, with links to the main doc might also be helpful.

Yep, I think a minimal getting started hello world would help a lot

I'm checking that now @tony.kay

Just confirmed only fails with alpha dom @tony.kay

@danielstockton Thanks for the feedback. I’ll add that to the list 🙂

@mitchelkuijpers Try 2.4.4-SNAPSHOT and let me know if that fixes it. I didn’t change localized-dom, just alpha.dom

Oh we use localized dom, but will try with alpha.dom

Btw, shout-out to @thheller shadow-cljs release app --debug is amazing for a developer, for debugging stuff like this

@mitchelkuijpers ok, I’ll fix localized as well and push a new version

@tony.kay Awesome, do you still want a minimal repro?

no

if that fixes it, it’s all good