Clojurians Log v2

@tobias Try 0.8.1-SNAPSHOT

on clojars

It's still 'broken' with 0.8.1-20170307.000421

hm. strange. I thought that would be it for sure

feel free to look around. I'm done for the day. brain dead

Same here 🙂 Many thanks, I'll have a look tomorrow, I've put a simple test case here - https://github.com/tobiasquinn/untangled-template/tree/issue-67-test-case

thanks, that will probably help

I'm getting this error after bumping untangled client version to 0.8.0

could someone paste a :dependencies section of project.clj that's working with 0.8.0?

Never mind, I copied it from https://github.com/untangled-web/untangled-client/blob/develop/project.clj

@urbank what version of clojure are you using?

look at the deps in untangled-ui

@tony.kay I copied the ones from untangled client, they seem to be the same as the ones on untangled-ui. It works now. Before I had clojure 1.8 so that was probably the issue

yeah, spec is a 1.9 thing

@gardnervickers Is #66 fixed (data-path)?

Yup! Thanks

@wilkerlucio Running through PRs. Can discuss yours in a bit if you'd like.

@tony.kay would love to, but I'm at work now, can you do in like 6 hours?

or we can do now, but I might get some delayed responses, hehe

I think the major point to discuss is about opening or not the option for the user to override Untangled reconciler definitions

why you think it's a bad idea?

Well, start with my comment I left on github. You can comment there or here. I'll have similar delays, so we can just do it in spurts 🙂

Does anyone know of any application examples on github using untangled? I'd like to read some source code to get some ideas and intuition about usage

@urbank You've found the cookbook?

the template?

or you're looking for something larger. I think the todoMVC is the biggest thing we've published, and it is full-stack

at least in the OSS space

@tony.kay Yeah, I think the cookbook has very specific projects showcasing specific solutions. I'll probably get something out of it, if I check it out again though. The todoMVC is great for a generic view, but it only has tow component types (aside from Root) where their relationship is parent child.

brb

I agree with you that part of what the community in general is missing is a larger "patterns library"

@urbank this is an open-source project I'm working on, you can check it for some reference: https://github.com/daveconservatoire/dcex-cljs

Om Next/Untangled both suffer from this

@tony.kay My worry is about get limited/stuck by the library, since this happened before and might happen again (like shared case, now this, and I'm afraid at some point someone might want to extend it). I don't think we need to document how to extend each option, a simple "WARNING: overriding reconciler keys can break how Untangled works, only override if you know what you are doing.". The way I see, Untangled should make easy to do the right thing, but without getting on the way when someone wants to change some behavior.

I'm with you, as I said in the comment. But from a practical perspective we do want to limit things. Should they be able to supply a parser? If they do, how do they compose in the correct data fetch story?

If they are supplying a parser, shouldn't they just use Om Next? A lot of what Untangled supplies might be better as plug-ins for Om Next, but that then makes the "reusable library of components" harder, because you need some of the decisions we've made to be in place to have a stable foundation for such libraries.

Go off and choose DataScript, and you've lost many of the benefits

The File Upload is a great example of both your point and mine. I had to expand the internals to accomodate what I wanted

but that needed to be done as an expansion of the Untangled system, not an ad-hoc add-on

willy-nilly overrides on the reconciler worry me

I'd rather address them one-at-a-time as we find compelling reasons to open them up

or open up all of the ones we don't care about

and treat the ones we manage as ones to be discussed as the community finds a need to mess with them

in particular the networking, remotes, and merge behaviors should not be generally open at this time IMO

(any more open than they are in 0.8, that is)

multiple remote + custom networking is already available, and we've got a standard database format with merge behavior that is somewhat advanced and nuanced.

one example I can think of changing the parser is to still be able to use explicit remote calls on the way Untangled does (which I would choose every time over how base Om.next does), and do a custom parsing (maybe Datascript?), I agree with you that this should not happen most of the times, I'm seeing this as a last resource, something that can be sold as "Untangled does all this management for you, but you can always override things if you are in a very edgy case"

I'd rather cover that case with a reader plugin

don't break mutation...it is a critical part of reusable components

but yes, having read parsing be hackable would be possibly useful

@wilkerlucio Thanks for the link, quite a lot of code, looking forward to studying it!

I'd rather see that as a pluggable chain, with db->tree at the end. You compose in ala Ring

something like that

again, not the raw reconciler option

more like what we do with the new server modules support

if one parser doesn't handle it, then the next in the chain does

@urbank have fun, if you don't understand something feel free to ping me, I'll be happy to try on clarifying 😉

actually, that is exactly how I'd do it

you can compose in a custom parser in front of Untangled's. If it returns nil on a request, we run ours

@tony.kay ok, so, which keys you think need to be locked?

that would let you plug into the read and write side

I like the chained parser idea, agreed that can work for parser overriding

locked ones:

:merge-ident
:merge-tree
:remotes
:send 
:state
:parser
:normalize

and send really isn't networking, it is the pipeline story that eventually connects to networking

so networking is already fully pluggable

We could open a separate issue for parser chaining. I don't need it, but possibly someone will contribute it

or you can do it while you're there 😉

hehe, maybe another time, but later today I can change the merge order, so Untangled keys don't get overwritten 😉

@tony.kay in the meantime I think we should create an issue for the chained parsers, so if other people have interest they can discuss about it on the issue

k, thanks

re: om-css in cljc: I have something, just want to play with it a bit until I am confident it works well and I'll raise a PR then.