Not sure if there is docs about it (or even if it's itentional), but om/fulcro ui-view plays nice with [reagent {:render "foo"}] 😮 (I'm porting reagent views to fulcro)

Fulcro’s React output is intended to be 100% compatible with a raw js react component. The queries and idents are about state handling and database normalization…so not too surprised 🙂

@jasonjckn Another new tool lets you know when your client state falls foul of being normalized: https://github.com/chrismurrph/default-db-format

I am using the bootstrap components for some navigation based on the example in the docs. Everything works fine in a defcard - but when mounting in the app, I’m getting

core.cljs:9133 Uncaught Error: Doesn't support name: 
    at cljs$core$name (core.cljs:9133)
    at fulcro$ui$bootstrap3$Nav.render (bootstrap3.cljc?rel=1518784216874:657)
    at react-dom.inc.js:5199
    at measureLifeCyclePerf (react-dom.inc.js:4479)
    at ReactCompositeComponentWrapper._renderValidatedComponentWithoutOwnerOrContext (react-dom.inc.js:5198)
    at ReactCompositeComponentWrapper._renderValidatedComponent (react-dom.inc.js:5225)
    at ReactCompositeComponentWrapper.performInitialMount (react-dom.inc.js:4765)
    at ReactCompositeComponentWrapper.mountComponent (react-dom.inc.js:4661)
    at Object.mountComponent (react-dom.inc.js:11409)
    at ReactDOMComponent.mountChildren (react-dom.inc.js:10314)

have you tried by elimination to see what's the bit that's causing the error ?

@claudiu So - beginner error - I hadn’t properly set up root query/initialization to pull in the navigation. The error was a bit obscure.

I do have a question on where to put mutations. In the template code - there is a clj and a cljs file for server side and client side mutations. The bootstrap navigation mutations is client-side - so I put the mutation in the cljs file - but it did not seem to find it. Putting it in the cljc app.ui.root file worked - but that’s clearly not the right answer. Thoughts? Still ramping up on where everything goes and how to connect all the pieces.

@donmullen So mutations in the cljs files, the only need to be in the clj part if you're also sending them to the remote. Not finding them sounds strange, are you using the multimethod or defmutation ? 🙂

@claudiu: defmutation

That code is straight from the fulcro book’s bootstrap sample. Running from server /index.html I get the following and navigation clicking on the tabs does not work :

[  1.255s] [fulcro.client.impl.application] Mutation  fulcro.inspect.ui.transactions/add-tx  failed with exception Error: Assert failed: Path [:fulcro.inspect.ui.transactions/tx-list-id [:fulcro.inspect.core/app-id nycdvp.ui.root/Root] :fulcro.inspect.ui.transactions/tx-list] for append must target an app-state vector.
(vector? (get-in state data-path))

how are you calling the transact! on select-tab ?

Again from the sample code @tony.kay provided :

(b/ui-nav nav :onSelect #(prim/transact! this `[(select-tab ~{:tab %})]))

Ahh :) that might be it.

Try importing your mutations file there and add the alias like m/select-tab

@claudiu - that worked - the mutation was found. Thanks! Thoughts on that above Mutation Assert failed?

Clearly app state is not in great shape!

I’ll move back over to devcards and inspect.

Not really 😞 haven't seen that error before. Don't know exactly what fulcro inspect is picking up. You can also add namespace like defmutation route/select-tab and as long as the multimethod can pick it up, you shouldn't need to import just add transact! route/select-tab

OK - thanks for your help @claudiu - much appreciated!

you're welcome 🙂

@donmullen - just wondering how Fulcro itself would report the error. You can always remove the Fulcro Inspect tool by removing it from :preloads and (reload-config) from the Figwheel REPL.

@cjmurphy - the cards build doesn’t include inspect - and isn’t giving any error - trying now for dev build.

@cjmurphy - same - no error reported from Fulcro with Inspect removed.

Wondering why Inspect is not preloaded by default for cards in the template.

I would guess the thinking was that each card has its own way of inspecting, and there isn't supposed to be that much state with each card, so there isn't so much need for Fulcro Inspect.

I personally like to use inspect on devcards, and the support for multi-app was made primarily with devcards in mind (so to support inspecting many different cards)

@jasonjckn Hey, long time no see! The impetus for the 2.0 fork of Om Next had everything to do with usable history navigation. Dynamic queries in Om Next completely break history serialization, and really you can’t even use any kind of history reliably in it…not even if you haven’t serialized history. So, one huge change internally is how dynamic queries work. From there, I’ve been trying to find holes in the API and fill them. I think most of the best stuff has been mentioned: ptransact!, compressible-transact!, serv-side rendering has been in for a while, but there are some additional helpers, significant changes to the rendering internals (include support for new rendering modes that can eliminate the need for follow-on reads), multiple targets on reads, history GC doesn’t throw away past steps that are related to in-flight network requests (enables new paradigm of time-travel error handling), defsc is not only a complete replacement for defui that is way more compact, it does all sorts of sanity checks which dramatically reduce head-scratching, forms-state is a lot less heavy version of form state and diff helpers for doing forms, there is no longer a need for a compiler hack to get adv compile to work, there is an option to use low-level raw inputs instead of the wrapped ones (which were to fix an IE bug I think, but break newer react refs), merge joins are a huge boon to mutations, allowing them to return an auto-normalized graph of data, you no longer need :ui/react-key (forced root refresh actually works without it), expanded various helper namespaces like html-entities and bootstrap3 (though I would consider this stuff that will probably be exported back to a UI library, and am leaning towards encouraging people to just leverage a lot of the standard React ecosystem for that concern). In progress: the new websockets support, which is much cleaner code and has better hooks. New remoting support that includes middleware that makes it possible to cancel network requests, consume progress events, and also makes it easier to adapt to things like file uploads without having to write the low-level network code and interaction. A rewrite of the internals of i18n to fix a number of issues. Fulcro-SQL is more of a demo library, and I think Wilker’s path-om library is going to be huge with Fulcro. It makes most of the rest of the hard edges rounder: interacting with REST APIs, consuming GraphQL APIs, making customizable client query engine, joining together disparate microservices into a unified Fulcro graph API, adapting to arbitrary server database technologies, etc. It’s the glue that will eliminate a lot of custom hand coding. Oh, and the devcard-fulcro support is pretty solid now: maintains application state on hot code reloads, and makes it super easy to run (portions) of an app in a dev card. Additionally, there’s a server emulator (used in the book) that is handy on cards as well for development. And then there’s an often-overlooked ui-iframe that lets you embed a portion (or entire) app in an iframe on the page. This is super-handy in devcards where you might need a clean-room for CSS, but it is also quite useful for portal-style apps. In normal js-land an iframe is a pain. In Fulcro/React you can render into an iframe but the js stays running in the parent page! This eliminates a ton of complexity, and makes it as easy as using any other DOM element because there is zero communication overhead. There is no js in the iframe…it’s just a rendering container that gives you shadow-dom-like abilities. I’m not a CSS guru, so I don’t know if the latest CSS yet supports a good way of making an iframe behave more like a container you can reasonably size on the page.

I guess I can also mention that I’ve found and fixed a number of bugs that were in Om Next that I had no control over before.

@tony.kay wow! sounds like you’ve been busy, and also really polishing the learning curve & usability of vanilla om.next which is definitely the main bottleneck on scaling up with more developers with very minimal CLJ/CLJS experience . Thanks for the write-up, will pass this info along to our CTO too.

@tony.kay our untangled app is still very much largely successful within the company (administrative tool)

i haven’t personally been working on it, since i’m a backend engineer, only went to front-end for the purposes of untangled with my long clojure experience but our tool is still being actively contributed too with new features , team of 2-3 devs

The frontend team is building a new project consumer facing, i’ve been trying to push fulcro for this internally, but i’m also not trying to get too involved as well 🙂

The GraphQL vision is interesting to us, we definitely have a lot of microservices, and right now we expose a plethora of HTTP APIs

Making this super simple & similar feature set of GraphQL server / facebooks specifications & killer demo would help sell this as a unified architecture for our backend to the team

As I recall untangled server it seems a little too coupled to webapp use cases, whereas GraphQL server is meant to be the unified endpoint for your entire backend distributed system essentially, security, auth, etc, etc. Maybe outside the scope of your work, but thought I would mention the use case.

@jasonjckn did you check out https://github.com/wilkerlucio/pathom ?

@jasonjckn in terms of expressiveness, graphql and the fulcro query have very similar features (although graphql needs more "internal" features like parcials and variables, in CLJ it's just EDN so we don't need those, just use clojure), and in pathom I'm trying to give a good framework to write such apis, it's on works a feature called Connect, using it you get an index containing a rich set of information about how your attributes relate, this index can be used to provide auto-complete features for editors (already present at OgE: https://github.com/wilkerlucio/oge), visualizations and other cool stuff, you can find a demo video about it at: https://www.youtube.com/watch?v=60i9uStI9As

@wilkerlucio interesting video, that’s definitely the sort of GraphQL server equivalent functionality I had in mind, OgE is icing on the cake. Would it be hard to have optimizations for answering queries as efficiently as possible, I would want as much batching as possible, e.g. several different om.next expressions don’t translate to several API calls on spotify but they get batched into a single API call when it makes sense, that may be outside the scope of pathom (?) but it’s also outside the scope of transit

this is especially applicable to mutations

@wilkerlucio Is this a passion project, or tied to corporate work

@jasonjckn batching is possible, the good part about having the entire query together is that you can analise it and take decisions ahead of time, I didn't have done yet, but I'm confident it should be possible, but how to do it depends a lot on what you calling, so it's hard to make a general thing

what can be done is more specific stuff, for example optimizing SQL queries that are implemented on this way

the GraphQL integration is another example on how that works

the current pathom server integration with graphql works like this:

once a graphql attribute is found (and going ot be parsed) the algorithm looks back on the parent query, and from then scan all the graphql items linked on that same query (siblings and children), extract just that query and send to graphql in 1 single batch, the batch is received, merged on the current entity and the parser goes on

when it finds attributes that are already fetched, just read from the current ident\

pathom is mostly a passion project, I've been working it pretty much since om.next was released, initially was just something that I copied over from project to project

but at nubank I'm starting to have more serious use cases, and that is driven the library to grow, there still so much to do there

link to LOC ? “d from then scan all the graphql items linked on that same query (siblings and children), extract just that query and send to graphql in 1 single batch”

https://github.com/wilkerlucio/pathom/blob/master/src/com/wsscode/pathom/connect/graphql.cljc#L241-L250

thanks

yeah really cool work , will keep my eye on the project

would you say it’s tested in production?

yeah, its been under prod usage at nubank on the backoffice

the graphql bits I would say is still experimental

the core engine is stable, connect still have a lot of room to improve, but had been working nice so far

yah i like it, certainly reduces a lot of boilerplate found in facebook’s graphql server configs

cool, that's our ultimate goal, make things good, simple and fast 🙂