Fork me on GitHub
#untangled
<
2017-03-07
>
tony.kay00:03:32

@tobias Try 0.8.1-SNAPSHOT

tobias00:03:11

It's still 'broken' with 0.8.1-20170307.000421

tony.kay00:03:33

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

tony.kay00:03:27

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

tobias00:03:58

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

tony.kay00:03:14

thanks, that will probably help

urbank12:03:19

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

urbank12:03:43

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

tony.kay16:03:22

@urbank what version of clojure are you using?

tony.kay16:03:56

look at the deps in untangled-ui

urbank16:03:47

@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

tony.kay16:03:02

yeah, spec is a 1.9 thing

tony.kay16:03:53

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

tony.kay16:03:06

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

wilkerlucio16:03:44

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

wilkerlucio16:03:44

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

wilkerlucio16:03:16

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

wilkerlucio16:03:31

why you think it's a bad idea?

tony.kay17:03:19

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 🙂

urbank17:03:26

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

tony.kay17:03:48

@urbank You've found the cookbook?

tony.kay17:03:06

the template?

tony.kay17:03:26

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

tony.kay17:03:36

at least in the OSS space

urbank17:03:58

@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.

tony.kay17:03:58

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

wilkerlucio17:03:06

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

tony.kay17:03:11

Om Next/Untangled both suffer from this

wilkerlucio17:03:21

@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.

tony.kay17:03:46

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?

tony.kay17:03:01

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.

tony.kay17:03:24

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

tony.kay17:03:02

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

tony.kay17:03:27

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

tony.kay17:03:57

willy-nilly overrides on the reconciler worry me

tony.kay17:03:18

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

tony.kay17:03:35

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

tony.kay17:03:57

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

tony.kay17:03:29

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

tony.kay17:03:57

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

tony.kay17:03:36

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

wilkerlucio17:03:22

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"

tony.kay17:03:08

I'd rather cover that case with a reader plugin

tony.kay17:03:28

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

tony.kay17:03:42

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

urbank17:03:04

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

tony.kay17:03:32

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

tony.kay17:03:40

something like that

tony.kay17:03:45

again, not the raw reconciler option

tony.kay17:03:15

more like what we do with the new server modules support

tony.kay17:03:26

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

wilkerlucio17:03:34

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

tony.kay17:03:34

actually, that is exactly how I'd do it

tony.kay17:03:01

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

wilkerlucio17:03:10

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

tony.kay17:03:12

that would let you plug into the read and write side

wilkerlucio17:03:50

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

tony.kay17:03:32

locked ones:

:merge-ident
:merge-tree
:remotes
:send 
:state
:parser
:normalize
We already allow customization of a few (e.g. :state isn't really locked, but it has logic in front of it). :migrate, :shared, and :pathopt already allow overrides (be careful around :migrate...`tempid-migrate` has to be the default).

tony.kay18:03:59

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

tony.kay18:03:16

so networking is already fully pluggable

tony.kay18:03:59

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

tony.kay18:03:38

or you can do it while you're there 😉

wilkerlucio18:03:36

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

wilkerlucio18:03:45

@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

nha20:03:51

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.