This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # alda (1)
- # aws-lambda (23)
- # beginners (27)
- # boot (156)
- # business (2)
- # carry (4)
- # cider (1)
- # cljsjs (2)
- # cljsrn (29)
- # clojure (170)
- # clojure-austin (35)
- # clojure-czech (8)
- # clojure-dusseldorf (5)
- # clojure-italy (4)
- # clojure-nl (1)
- # clojure-quebec (2)
- # clojure-russia (45)
- # clojure-spec (49)
- # clojure-uk (12)
- # clojurescript (81)
- # component (5)
- # datomic (24)
- # devcards (26)
- # emacs (4)
- # hoplon (4)
- # jobs (1)
- # juxt (5)
- # leiningen (6)
- # luminus (14)
- # mount (26)
- # om (27)
- # om-next (2)
- # onyx (22)
- # pedestal (2)
- # planck (3)
- # proton (5)
- # re-frame (19)
- # reagent (2)
- # ring-swagger (60)
- # spacemacs (12)
- # specter (8)
- # untangled (119)
- # vim (61)
- # yada (36)
@tony.kay I don't know if there's a way to replace a pull request, so I just make a new one.
e.g. do a
git reset --soft ..., then commit the work as a single patch, then force-push
@grzm one more tip (I can take care of this one): we work against the develop branch (git flow). Master is for releases.
@mitchelkuijpers FYI, I'm continuing to work on the template (in the template workspace project I mentioned earlier). I've added full support for running all tests from the command line (cljs and clj) for CI.
I also added some example "extra routes" for REST integration with other clients, commented the sample of hooking into the Ring chain, and beefed up the README quite a bit
there is no global idea of fallback, since the transactions are meant to be abstract mutations that need some kind of rollback
But, a helper function that always includes some specific fallback in your mutations is trivial to write
@ethangracer Did we ever get to the "clear the network queue" as a function ppl can call?
the last modification I remember making was to add the previously received error to the lop level of the app state
not that there’s any harm in having it run if it isn’t implemented and just returns nil
the global callback is built into the networking layer object, which (if you override) is lower level
@jasonjckn @tony.kay see here for a higher level explanation of the error handling, if you haven’t already https://github.com/untangled-web/untangled-cookbook/tree/master/recipes/error-handling
Yeah, we still need the ability to say "stop processing the stuff that's optimistically queued"
I thought that everything was batched and sent at the same time, in one transaction
say you did five things in the UI, and the first transaction has gone remote, the rest are waiting
we rewrite tempids in the queue to deal with the fact that "add" will respond with a rewrite
but we have no way for the app to say "yeah, throw out the rest...nothing else will work"
What you're missing is that these are separate UI interactions, and the net is slow...so it was multiple calls to
much more complicatd to write fallbacks that "undo" the optimistic things in a predictable manner
much easier to say "reset to the point there was no list and stop processing" (in the sample case)
but the flip side: you really do not know what is on the queue...so clearing it might leave you in an inconsistent state
It might be that the only case you ever want to clear are those that involve tempids that were in the failed tx...perhaps we just auto-clear those?
it's really the ones that are trying to work on a thing you failed to remap that are going to be a disaster...oh, but how can we know the difference?
Yeah, unhappy path handling with optimistic updates opens a can of worms. If I had to guess: most ppl will just reset the whole app if an error occurs.
@tony.kay sorry got distracted by another task. that’s exactly what we’re doing in insight — click to reload for everything. works like a charm, though it’s definitely a case of “if all you have is a hammer, everything becomes a nail"
@tony.kay thnx, I got a go from my team on moving to untangled. But you can probably expect pull request for every lein plugin for a boot counterpart, because we won’t move away from boot. I hope you don’t mind ^^
We are also very interested in the untangled i18n solution, we would love to remove our dictionary.clj for translations.. because it is always out of date 😛
I am just watching the "Untangled Web Framework at Portland Clojure Meetup” youtube very funny to see a part about not using query parameters for the ui… I used the beginning and after a lot of fighting we would just put them in the app state and trigger the right refreshes. Solves so much problems.
I just pushed UC 0.5.6-SNAPSHOT to clojars. This adds support to the UntangledApplication interface: - Ability to clear pending network requests - Ability to reset app state to original (as if just loaded), along with trigger a possibly alternate callback - Mitchel's reset history support...oh, wait, I guess I should include that in reset app 🙂...will push again in 5 mins
Btw one small question, if you load data from the server let’s say
:contacts/list and I want for some reason two lists, is it possible to somehow say merge this list in
:contacts/list1 and load this with different params in
So, the stock Om idea is you write a parser so you can send queries to the server, have them come back as a tree, and then your parser can construct the various alternate views once that data is normalized.
So, in Untangled the load functions have a post-mutation parameter. The idea is that you morph the server response after it's been merged
yeah, it just takes all that inherent complexity away...you've got to reshape stuff...why not reshape it directly?
Not to insult anyone on the channel (or myself for that matter), but most engineers find direct data transforms easier than parsing logic
(integrate-ident! state [:thing 2] :append [:people/by-id 4 :things]) is an example of that helper...
does some sanity checking for you too...eliminates mutation bit-twiddling on normalized databases, since a lot of what you do is pepper idents around
We currently have no testing story for the ui, we do selenium testing. But we will probably start using spec for the app-state testing
No I think I missed it, we only use selenium for our happy paths but it they are mainly so we feel confident and we are creating a JIRA Addon. So we will detect early if JIRA breaks our addon
We are building on atlassian connect and the way it works you can install addons on jira cloud and we will get an Iframe in a part of the application or we will get a complete Iframe for the page. This has some pretty nasty complications as you can imagine…
@mitchelkuijpers, we are a boot shop happily using untangled for over 5 months now
we haven't needed to write any custom untangled boot tasks, though we don't use the internationalization thingy
@currentoor Aha cool, I’ll remember that if I have any questions. I think we will look into the internationalization thingy but not in the near future, but shouldn’t be too hard to make that working 🙂