This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # arachne (3)
- # atlanta-clojurians (5)
- # beginners (6)
- # boot (37)
- # braveandtrue (1)
- # cider (128)
- # clojars (3)
- # clojure (224)
- # clojure-belgium (5)
- # clojure-boston (43)
- # clojure-czech (8)
- # clojure-france (2)
- # clojure-greece (17)
- # clojure-hamburg (4)
- # clojure-russia (285)
- # clojure-seattle (1)
- # clojure-uk (12)
- # clojurescript (209)
- # core-async (2)
- # core-matrix (8)
- # core-typed (1)
- # cursive (2)
- # data-science (2)
- # datascript (1)
- # datomic (18)
- # emacs (12)
- # events (2)
- # hoplon (15)
- # immutant (1)
- # jobs (1)
- # ldnproclodo (23)
- # leiningen (10)
- # mount (8)
- # off-topic (7)
- # om (126)
- # onyx (6)
- # overtone (2)
- # parinfer (5)
- # proton (24)
- # re-frame (16)
- # reagent (14)
- # untangled (105)
- # yada (1)
hey guys, I’m considering making a change on untangled-client involving
untangled.client.mutations/post-mutate, and I’m wondering if anyone is using it?
I've been looking at re-frame, and it makes a lot of sense to me. I actually wrote a gui app for Google last year that had a very similar architecture- not as FRP, because it was in Python, but... as similar as you can get in Python. So re-frame makes a lot of sense to me, intuitively. Nice and simple.
Om.next is a bit of a puzzle to me, and I am sure that is only because I don't understand it.
Ah...so, I have not looked at re-frame, but I need to. We're developing Untangled for our own purposes, started on it before r-f. Untangled makes om.next quite a bit easier, and the docs we're building should make it quite easy.
So- and here is the contentious part- what is the advantage of Om.next? It looks complicated to me.
Right...simple vs easy. Om.next's central idea is quite elegant and simple, but foreign.
I think we can agree that any nice framework in cljs is excellent work- I'm not asking you to say that re-frame is bad, etc.
then it has some complex bits (the parser)...that in my opinion are not really even needed on the client
I talk about the general merits of Untangled/Om.next in the portland meetup talk....that is the best I can do
it takes quite a bit of time to cover the "why", but that talk is my take on most of it
though it does assume a bit of knowledge about om.next....the Clojure West talk (also on YouTube) is a better beginner's guide.
Reagent encourages a lot of embedded state, doesn't use a central atom (no support viewer), etc. I think in the small it is great. In the large, maybe not as great...but lots of ppl build great stuff with it, so YMMV
im reading up on re-frame and it looks like it’s more of a pattern than a framework/library, and it uses a single source of truth
From what I see, the lack of a server interaction story seems to be a big missing bit. Om next/Untangled have a nice full-stack story
The thing that really made me sit up and take notice with some of the clojurescript frameworks is how they resembled the ad-hoc stuff I've been doing for a while, but hadn't really reasoned about.
Quote from website: To build an app using re-frame, you'll have to: design your app's data structure. write and register subscription functions (query layer). write component functions (view layer). write and register event handler functions (control layer and/or state transition layer).
I have actually really had to fight with people to get the "single app state" accepted as a reasonable idea.
The first 3 sound like Om/Untangled. The last is just different. In Om these are top-level abstract transactions. But they do actually sound quite similar
from the parts that ive read:
re-frame => om-next
The Signal Graph =>
Event Flow =>
i can tell you from having read the re-frame readme that untangled covers a lot more ground in terms of getting a production application up and running
things like config, internationalization, server stack, (full-stack) testing, etc...
@amashi: transient state in untangled can be handled either with React's component local state or a special namespaced keyword that doesn’t get sent to the server, so even though it goes in your app state, it never pollutes the server interactions
Interesting. Does untangled have an opinionated view of synchronizing client state with server state?
I should note that I write a lot of hybrid apps- js running on phones with intermittent connections.
currently you write a client side mutation and you return a map with
:action for optimistic/client side updates
and for each remote you would put under its name the value true or an updated ast (which you can think of as the params being sent)
Where I have to give the user instant feedback, but be able to roll back user actions when they don't succeed.
And that's of course something that no framework can handle- you need policy for that.
and then i think untangled keeps a queue of remote messages so it’ll send them off when it can
and then we’re working on polishing the
tx/fallback case, which is what you called “rolling back user actions when they didn’t succeed"
the basic idea is that you tell it the name of the mutation to run in case things didn’t succeed
Well, the devil is in the implementation details, but having first-class support for that would be great.
The last client project I did was a hybrid app, and... you wouldn;t believe how much code in it was about handling errors sensibly.
well i would say at navis we all want it done well, and you are in the right time period to involved in the discussion and design of it
There is more work with reframe because of all the subsrciptions/reactions. With Om Next you don't even have to think about those, even as your components become quite complex. See the amount of work Colin Yates had to do just to get a table going with reframe.
It is of course something that can;t be solved, really, by any tech. Policy is important.
(in case i just threw out a name, navis is the company all of us working on and with untangled work at)
Ah, OK. I will take a look at that. Thanks @cjmurphy. It is precisely cases that re-frame doesn't handle well that I am asking about.
tony mentions this in one of his talks, but untangled is the framework to move the company from VB/.NET
It's not that I think there aren't great programmers on the platform- there clearly are.
It;s just that every time a client asks me to deal with their backend people on dotnet it turns into an insanely bad scene.
@amashi: no offense but I recommend you don't proclaim your prejudices so casually. There really isn't much to gain by doing that IMHO.
I suppose the bigest question I have is a simple one. What does Untangled/om.next do better than other frameworks?