This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-07
Channels
- # beginners (49)
- # boot (48)
- # cider (5)
- # cljs-dev (6)
- # clojure (165)
- # clojure-android (1)
- # clojure-austin (1)
- # clojure-india (2)
- # clojure-italy (23)
- # clojure-nl (2)
- # clojure-poland (4)
- # clojure-russia (63)
- # clojure-spec (5)
- # clojure-uk (121)
- # clojurescript (187)
- # core-async (1)
- # core-logic (4)
- # cursive (17)
- # datascript (1)
- # datomic (12)
- # emacs (2)
- # funcool (3)
- # hoplon (2)
- # jobs (7)
- # juxt (6)
- # lambdaisland (1)
- # luminus (2)
- # lumo (20)
- # midje (8)
- # off-topic (11)
- # om (38)
- # onyx (42)
- # pedestal (6)
- # planck (23)
- # protorepl (29)
- # ring (3)
- # rum (23)
- # spacemacs (6)
- # untangled (70)
- # vim (1)
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
Never mind, I copied it from https://github.com/untangled-web/untangled-client/blob/develop/project.clj
@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
@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
or you're looking for something larger. I think the todoMVC is the biggest thing we've published, and it is full-stack
@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.
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
@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.
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
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
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"
@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
@urbank have fun, if you don't understand something feel free to ping me, I'll be happy to try on clarifying 😉
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?
I like the chained parser idea, agreed that can work for parser overriding
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).and send
really isn't networking, it is the pipeline story that eventually connects to networking
We could open a separate issue for parser chaining. I don't need it, but possibly someone will contribute it
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