This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-16
Channels
- # atlanta-clojurians (8)
- # beginners (103)
- # boot (22)
- # boot-dev (1)
- # cider (36)
- # cljs-dev (55)
- # cljsrn (3)
- # clojars (25)
- # clojure (104)
- # clojure-brasil (1)
- # clojure-dusseldorf (2)
- # clojure-italy (8)
- # clojure-norway (9)
- # clojure-russia (15)
- # clojure-spec (6)
- # clojure-uk (26)
- # clojurescript (246)
- # cursive (26)
- # data-science (1)
- # datomic (22)
- # dirac (11)
- # editors (1)
- # emacs (8)
- # fulcro (50)
- # graphql (11)
- # hoplon (1)
- # jobs-discuss (27)
- # leiningen (44)
- # luminus (33)
- # lumo (2)
- # mount (1)
- # off-topic (8)
- # onyx (5)
- # parinfer (4)
- # reagent (94)
- # ring-swagger (14)
- # shadow-cljs (37)
- # spacemacs (10)
- # specter (3)
- # tools-deps (4)
- # unrepl (14)
- # yada (5)
Anybody have thoughts on kee-frame? It seems to be a Keechma inspired routing/controller approach on top of re-frame https://github.com/ingesolvoll/kee-frame
This article is pretty good: https://medium.com/@kirill.ishanov/using-containers-with-reagent-and-re-frame-ba88c481335d
But one issue we run into with higher order components is when the child component has arguments itself which it needs to re-render
@borkdude I’m not sure I follow what the issue is. Is the problem that you can’t pass the arguments through the hoc?
In the article only child components of zero args are used. Is there documentation on how to deal with this problem?
one solution would be to do it all with re-frame subscriptions and reduce the child component to a zero arg one
look at debounce here: https://google.github.io/closure-library/api/goog.functions.html
@tomaas, very common problem
basically input element are a never-ending source of issues with Reagent (and to a lesser extent, React and React Native)
@tomaas try this https://gist.github.com/pesterhazy/1c695cfcc15656165aa15ab326572c20 and let me know something along those lines works
... if you don't need to change the value programmatically, you can also use :default-value
instead of :value
(use an uncontrolled component)
that’s weird. i though reagent wrapped input elements specifically so that the dom got updated synchronously from the on-change handler. if it doesn’t do that then the cursor jumps around and it starts dropping characters.
@lee.justin.m but how would that possible work with :value
(suppose the handler function doesn't "accept" the change)
@pesterhazy I thought that it does some magic to ensure that the value gets updates right away. Let me take a look so I don’t say things that are wrong. I think the actual problem here is just that tomaas’s last render takes so long that the UI can’t update the input change.
yes there is magic in the reagent source
but it doesn't account for all possibilites
if you yield back to the event loop in between changing the atom and changing the dom, all hell breaks loose
in my experience at least
because if you do that, another event can come in with the old value of the dom and then a keypress gets dropped
Whats a popular server side for reagent apps? We are using cljs.nodejs but I wonder if some other native clj server side lib would be better
@lee.justin.m I'd love to understand fully what's happening. I feel I'm 80% there, but the remaining 20% are still causing trouble
this piece of code is the special handler: https://github.com/reagent-project/reagent/blob/master/src/reagent/impl/template.cljs#L207
the problem occurs especially when you use 3rd party input components (other React libs that wrap <Input>
)
(I'm guessing because Reagent can't guess it's an input element)
Reagent only does its magic if something feeds it a vector where the first element is ‘input’
And really you shouldn’t have this problem because you won’t be messing with reagent’s atoms if it is in a third party
all I know is that (awfully complex) piece of code doesn't work in all cases
and yes the problem occurs because of ratoms, which are batched and postponed until the next tick
there is more than one quirk they are dealing with. the most important one to understand is that when you press a key in an input, the next event contains the new value of the input element (not just the keypress), but does not change the dom. so most of the magic is designed to ensure that the dom gets updated in the same event. there is also an i.e. bug that is quite difficult to understand, but it basically results in a late on-change event.
@njj Do you mean serving compiled code or do you mean doing server-side rendering? If the former, I don’t think there is anything specific to reagent that matters: you can serve from jetty or node. It probably just depends on what your backend api server is on. (I have a JS backend so I server the front end bundle from node.)
@pesterhazy at any rate, I still suspect that there’s no real way to fix the problem tomaas is describing: I am pretty sure that if a render takes, say, 1 second to finish, the user input is going to lag no matter what. debouncing will help, but not solve, this problem
@lee.justin.m, there's also the problem that, if you add a buffer that gets updated before the proper ratom can, you have two sources of truth, and you need to decide which is authoritative
it's a tricky issue, if you want to be able to change the content of the input field programatically while it is mounted
oh yea that would be very gross given that you could change the input value while a change event was in flight
I almost lean towards using :default-value
and changing the input field manually when necessary (if you need to clear it for example)
using default-value, @tomaas's problem should be fixable for sure
yes, I think so
(no javascript involved)
@borkdude I’m not sure I follow what the issue is. Is the problem that you can’t pass the arguments through the hoc?
@lee.justin.m @pesterhazy I like the conversation on this. I have struggled with this before
honestly I think every Reagent user with a somewhat complex app runs into issues with input components sooner or later
I need to fix my problem actually. I have put it off for a few because I have fought with it before and it is a time sink
yeah react-select would be one example of a 3rd party lib that might expose this problem
it's an amazing library
very polished
if you put up a minimal repro, we could have a look together
I also want to get to the bottom of this, maybe blog about it
I wonder if people using redux (rather than component local state) are facing the same issues
I thought I mostly understood the problem, but everytime I think I understand i end up not really
I may be better off just abandoning that combination for what I was doing here. However, I still just in general like to try to under what is going on
yeah that might even be a problem with the React libs
I imagine there's nothing special (except for ratoms) in Reagent that causes these delays
I definitely ran into this issue when using redux, but I think it was just user error. There are bugs like this that are disconcerting: https://github.com/reactjs/react-redux/issues/525
And then there’s this ridiculous I.E. bug: https://github.com/facebook/react/issues/7027
And then the relevant fix in reagent: https://github.com/reagent-project/reagent/issues/253
@lee.justin.m thanks for the pointers. There's a whole cluster of different issues there, hard to disentangle
I’ve been on websites out in the wild where I saw this behavior and I was pretty sure they were using react hah
Perhaps everyone should just start typing slower into input fields - problem solved 😛
to tell you the truth, setting aside the i.e. bug, most of the issues I’ve read that had any clear information about this all seemed to be the same issue: don’t yield to the event loop before updating node.value. I suspect that any library that tries to update an input element with intervening events is going to be very hard to get right
I agree, but there are different reasons why the value is not updated fast enough
well if it's not synchronous, it'll be slow
obviously if you spin the CPU for 100ms in the on-change fn, that'll cause weirdness as well
(not that that's likely)
it’ll make it be janky, but if I actually understand this issue correctly (which is dubious to be fair), then it will be correct even if you spin. my understanding is that the browser will queue the OS-level keypress events while you are out on the onchange handler