Clojurians Log v2

Soo, is anyone using untangled-components? Would really like to start using it for the forms stuff

I’ll try to integrate the forms component next week into our untangled project.

There is already a very good documentation and introduction as an devcard in the developer branch.

https://github.com/untangled-web/untangled-components/blob/develop/src/cards/untangled/components/forms_overview.cljs

It’d be nice if the untangled team could publish the latest developer version as a SNAPSHOT to clojars. The latest published Version is from Oct 2016.

Yeah I checked the documentation out, but I will wait a bit longer till it is not snapshotted anymore. But there are some very nice ideas in there

hey there

@mitchelkuijpers @baris we have not published it because I got sidetracked on other important things. There are some rough edges that need cleaned up before the API is stable, I think

let me look real quick and refresh my memory...I'm wanting to use it too 😉

So, I'm willing to merge the current PR to develop and push a SNAPSHOT. Most of it will remain the way it is, but there may be some renaming of functions. I don't like some of the names and don't have time to deal with it at the moment.

OK, 0.1.0-SNAPSHOT of components is on clojars

Run/read the devcards forms_overview and forms_advanced

If anything is broken on those cards, assume it is a problem and report it. It is likely that the implementation changed and the card got left behind

The main recent add is that nested forms with recursive support for top-level reasoning was completed, along with a generic on-the-wire form submit (commit) was added that sends JUST the diffs of the entities (or the whole entity if it has a tempid)

you have to implement the server-side processing of that, but that should be pretty easy, since it basically tells you the ident (which can correspond to table/id) and the attrs that changed.

@adambros can chime in, but I don't think we've talked about doing anything that would cause major breakage if someone used it "as-is". I think mainly a bit of minor renaming, and possibly tuning up the specs

so fixing any code that depends on it when we stop snapshotting should be a few mins of work, and I can include the renames in the changelog

It’s Ok for me that there could be some renaming or so. I’m fine with that.

Thanks for shnapshotting and publishing @tony.kay

welcome

So, there is a performance bug in U.C., but unfortunately in order to fix it any applications that are improperly triggering post mutations may no longer render correctly (e.g. you could be lazy with the current bug, because it is forcing a root re-render). The proper behavior is for your loads to include a refresh-set of keys to re-render.

There is no way for me to fix this without causing potential unintentional breakage.

Is it only an performance bug in post mutations, or general performance improvement?

currently the internals are forcing a root rerender with a change to react-key if any post-mutations run

really, your loads should have refresh keys listed, and just those things should be re-rendered

It's just causing a full root-level react regen of the DOM

which is slow

Interesting. Wonder if that'd help improve our boot times (only place we use post-mutation)

possibly

how do you get away with no post-mutations elsewhere?

For the most part all of our data has a 1-1 mapping with what we get from datomic pulls, so we don't ever really have to do any post-processing of received data, and with Sente we receive updates for things we might otherwise clean up with post-mutations I guess?

nah...if your data already matches up, then it is easy

Yeah, we put a lot of effort into trying to make sure it's one-to-one for a pull query.

(well, pluck - https://github.com/AdStage/pluck-api - in our case, but that's just a bit of extra wrapper to simplify the read functions on the server side)

cool

so, it would not affect you