hello folks - wondering here about https://github.com/reagent-project/reagent/pull/126, i am experiencing the problem here that caret still goes to end whenever you change text input in the middle

its still happening for v0.6

@michael.heuberger given cursor positioning appears to still work for us (others?), I'd guess you are somehow re-creating the <input> each time a char is entered. But this is just a wild guess and I'm not sure how that might be happening, but, if it were, it would certainly cause the cursor to jump to the end each time (which is the behavior you are seeing). To check, stick some printlns into the parent view functions (which render the <input>) to see when they are getting rerendered. Other than that, I'm stumped.

hmmm, thanks. i dont know - using cljs-react-material-ui here in conjunction with reagent

I think the problem is that a Material UI textfield is a not a reagent.impl.template/input-component? so it bypasses all of the special handling in reagent-input, input-spec, input-handle-change, input-render-setup etc.

Confirmed the above suspicion; an evil workaround of doing a form-2 component with :display-name “input” that renders the Material UI textfield component in the render fn fixes the issue. Any ideas how reagent could support this use case better ? @mikethompson

@superstructor do you mean a Form-3 component?

Ah yes sorry, a Form-3 component! 😃

I don't know too much about Material UI @gadfly361 might be able to cast more light. I'm slightly baffled as to why a :display-name would have an effect.

@mikethompson all of reagents input special handling is based on reagent.impl.template/input-component? which checks if ($ parsed :name) (from native-element) matches ”input” or ”textfield”, otherwise it just renders it as a non-input component. Since Material UI textfield is a React component (not input or textfield) it does not pass that check.

Ah, right.

https://github.com/reagent-project/reagent/blob/v0.6.0/src/reagent/impl/template.cljs#L188 @mikethompson

That's a hell of a trick

I’m somewhat amazed that it works tricking reagent into treating a complex div/input structure as an input by renaming it! 😆 Well, at least for now there is a workaround. I cannot think of how it could be easily fixed in reagent. @mikethompson

@superstructor I’ve had the cursor jumping problem with material-ui too. I’ve fixed it by calling reagent/flush on each change.

In the frontend part of our application, we have had a habit of accumulating values into a map which is then passed on from component to component. Some of the values are only relevant for logical purposes, and a subset are relevant for passing on to the final "leaf" component, such as an `[:input]` or `[:span]` or whatever. Since we bumped our reagent version, and transitively our React version, React has been outputting warnings about for example: _react.inc.js:20209 Warning: Unknown prop `iconDisabled` on &lt;span&gt; tag. Remove this prop from the element. For details, see <https://fb.me/react-unknown-prop_>

This is because we pass our saturated map directly to the leaf component.

Now, I'm trying to figure out which would be the better solution. Destructuring the saturated map for only the values that we are interested in seems like the most sane solution, but it leads to having to add more stuff to the destructuring as we go along, and it seems silly to do all this only to recreate the part of of the map that we are interested in before passing it to the component. It seems like a lot of boilerplate.

And having to add to that boilerplate along the way seems silly, too.

So I thought, since the "legal" values for a particular element type are already known, perhaps someone has created a vetting function? Something like (sanitize-for :span saturated-map)

@mihaelkonjevic thats interesting re reagent/flush - did you add this inside the on-change fn before or after dispatching?

@michael.heuberger lm ’ve added it right after I’ve mutated the atom. I’m not doing any dispatching in that code. I’m using https://github.com/keechma/forms so I have atom at hand to mutate it directly

Hi all, I know that reverse debugging has been demonstrated in Clojure but has it been developed into a sort of more polished form a la elm-reactor (https://github.com/elm-lang/elm-reactor) ?

[I saw the recent frisk stuff come across and it looks like a huge step in this direction-- but as far as I could tell there's no reverse debugging aspect to it]

elm doesn't have a debugger yet. Evan only demonstrated a prototype and a goal for elm 0.18 at elm conf

I was referring to elm-reactor (which clearly exists and which had time-travelling debugging integrated in 2014 and yes which is temporarily removed but will be making a re-appearance soon).

There is a lot more the elm-reactor than the time travelling aspect as well.

And my question was in regards to the refined nature of the tool (which as far as I know has no analogue in the Clojure world; hence the question).

In fact, "refined" is not a word that leaps to mind about any Clojure tools anywhere in the Clojure stack to be honest (not even the ones that you get setup once with some magic blurb of code from some site and work primarily reliably for months on end but you never know how long that's gonna last and so you live in a constant state of fear of the worst).

Keeping a working Clojure setup is very much like keeping a working Emacs setup (and the two are of course intertwined if you are enlightened enough to use both).

@johanatan you might find this interesting http://metametadata.github.io/carry/examples/todomvc/

@gadfly361 yea, that is interesting. how does one go about integrating it into their project/setup ?

Take a look at carry https://github.com/metametadata/carry unfortunately cant offer much beyond the link

Oh bummer. Looks like it is a standalone framework. I'm already pretty heavily invested in re-frame

CC @metametadata