This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-19
Channels
- # 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)
Added a new one to the list there - more routing/browser history examples
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?
would you prefer i describe it here, private chat or in person?
Anyone have an example of how to create a migration with enums in datomic?
The code is a fork of https://github.com/Yuppiechef/datomic-schema
awesome thanks!
@currentoor: So, that answered your question?
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
as a note: re-frame is built on reagent if you know that one
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
they keep comparing themselves to elm
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
=> Query
Event Flow
=> Transactions
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 dont think its any more opinionated than om next
but that statement might need to be revised
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.
for intermittent connections the optmistic update covers the instant feedback
And that's of course something that no framework can handle- you need policy for that.
@tony.kay: yes that answered my question
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
and it can do any arbitrary action, eg: refreshing, showing an error dialog, etc...
does that answer it?
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.
no worries, we’re in the hospitality industry
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.
its not even the .NET that scares me (see F#), but the VB part
@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.
especially when there could very well be ".net people" here
lets get back to #C0PULSD25, do you have any other questions?