that'd be cool!

@mattly I once started (but never completed) a tool like that: https://github.com/pesterhazy/unspector

another data inspector widget for clojure would be very welcome (there already is https://github.com/Odinodin/data-frisk-reagent which I love)

A while back I was reading an article somewhere about a way to avoid form 2 components that merely need to be wrapped in local state atom by using some function or macro "with-state" or similar and then defining what looks like a form 1 component, but for the life of me I cannot find this information any more. Anyone have any idea what I'm talking about?

looks like I was thinking about this: https://github.com/reagent-project/reagent/blob/master/docs/CreatingReagentComponents.md#appendix-b---with-let-macro

with-let is useful mainly for disposing of resources I think

if you don't need that, Form-2 seems clearer to me

Anyone here able to use [cljsjs/react-transition-group "2.2.1-1"] successfully? I seem to always get Undefined nameToPath for react_dom or Undefined nameToPath for react after including the dependency. I have tried with :exclusions [cljsjs/react], :exclusions [cljsjs/react-dom], and :exclusions [cljsjs/react cljsjs/react-dom]

I'm using reagent 0.7.0

@ajs, https://reagent-project.github.io/news/news060-alpha.html

with-let allows an optional finally clause, which gives you a chance to clean up after yourself

unless you need that feature, Form-2 seems clearer to me

@curlyfry you’ve got conflicting dependencies somewhere

https://github.com/cljsjs/packages/issues/1422

@lee.justin.m That was my suspicion, which is why I tried the different :exclusions i mentioned. Didn't help at all though.

are you using lein & cljsjs or some other mechanism to import?

I suspect that the version of r-t-g needs a version of react different from the one you are ending up with

No use just blindly adding exclusions, check dependencies tree to confirm conflicting versions and then use exclusions or other solutions to ensure correct versions

Oh I think I can guess the problem

React-transition-group Cljsjs package uses new-style names (to support global exports) so it tries to use react foreign-lib which is provided by new Cljsjs React packages, but not the old Cljsjs React version used by Reagent 0.7

[cljsjs/react "15.6.1-2"] [cljsjs/react-dom "15.6.1-2"] in addition to new react-transition-group package should work with Reagent 0.7

@juhoteperi Hmm, interesting! Will try it tomorrow. Thank you!

That seems a bit subtle though, not sure how one would be able to figure it out without keeping close attention to changes in cljs. It's also possible I'm just dense.

I'll try getting 0.8 out soon. Should help with this kinds of problems.

Very much looking forward to 0.8 🙂

@curlyfry I don’t think it is reasonable. cljsjs is a fragile solution, in my opinion, and really only works when libraries are independent. as you try to add more react libraries into your program, for your sanity you’ve got to use another solution

@lee.justin.m What aspects of cljsjs make it more fragile than other dependencies?

Some of these changes, like global-exports and using npm names on cljsjs libs, are to help with transition to other solutions, without breaking existing projects

for starters, if you have a single dependency that isn’t on cljsjs, suddenly the whole dependency management is broken

interesting stuff, what solution are you using for js deps @lee.justin.m?

I go with shadow-cljs, but the webpack solution is robust too. https://gist.github.com/jmlsf/f41b46c43a31224f46a41b361356f04d

I'll check it out. What about :npm-deps?

ClojureScript compiler Node module support (i.e. :npm-deps) is experimental feature

:npm-deps will run your library through advanced compilation and its resolution algorithm is not a 100% replica of npm, so it might work sometimes and get you good results, but it isn’t robust at all

also the error messages are just awful and unless you want to look at the source you’ll never be able to debug problems with it

0.8.0-rc1 is out now: https://github.com/reagent-project/reagent/blob/master/CHANGELOG.md#080-rc1-2018-04-11 Not planning any more changes but I decided for one more release before final to ensure defaulting to React 16 doesn't cause huge problems.

Question about r/current-component I have heard some argue that they do not use this as it adds too much OO into clojure. In preference, they might do something like:

(def node (atom nil))

:component-did-mount
(fn [this]
  (reset! node this))

@tkjone Why do you need the current component outside of the lifecycle methods anyway? The question to me is confusing.

Let me add some more code:

(defn some-component
  [_]
  (let [node (atom nil)
       other-func (;;using r/props here)]

      (r/create-class 
          :component-did-mount
             ;; stuff here))

where I have written ;;using r/props here we are using this we stored in the node atom above. So its a way to access this.props in a claasic react way

where does other-func get called? if its being called from the render-func you can just close over the props there. if its being called from the lifecycle funcs, you can get props from this and then pass them in

but to answer your question: the “OO” aspects are inherently introduced by react, not reagent. I don’t see how either method makes it more or less “OO”

other-func is called in :reagent-render

So you have the props right there, don’t you?

the reagent-render’s argv is the props

sorry, other-func is passed to another component in :reagent-render

so its not called till later

whoa that is confusing 🙂

whose props does it want?

the parent component

if you want a non-OO solution, maybe the better thing to do is use partial with other-func before you pass it

are there examples of this in the wild?

i haven’t needed it. but it would be somethinge like (defn f [prop1 prop2 something-else] ...) then when you pass it, instead of passing f, you pass (partial f prop1 prop2)

then when it is called you pass something-else assuming it needs more args

nice, thank you

in the end, I wanted to vet this approach, I don't see a need either.

I’m converting javascript to cljs right now. I use partial sometimes when I want to break a class method out of the class and make it a function, but you need a particular signature b/c its a callback. In JS, you just set stuff on this and then make the signature whatever it needs. In cljs, you can add the data that was previously set on this to the function signature, then use partial to bind them.

Interesting. So you are using partial, as an example, if you have a class and said class has functions defined inside of it. This allows you to remove those functions in the class so they are standalone functions

how do you deal with the case where this extracted function now requires so many args because previous, it could just access variables as they were in its scope?

I don’t know what the right solution is. I only use this technique when the function “feels” like it can or should be standalone (which is more often than you’d think). If there’s inherently a lot of data being passed, then maybe the solution is to pass a big map that effectively operates as “this”. One of my components renders a pdf to a canvas and is just inherently a big ugly stateful class. I literally merge the props into a state atom and just mutate it like it was the this

btw long potentially relevant thread on this in #clojure

But my basic rule is that if you can get away with just passing two or three things, do it. The function is easier to understand not only in terms of understanding its implementation, but also in terms of understanding its use at the callsite.

That has been my approach also.

the conversation you are referring to is the thread, yes?

yea. kind of related in an abstract way

I can see it.

I would like to see how dnolen would handle these situations in real world apps.

the real world is an ugly place with no room for purity 🙂

Very true, and I feel that Clojure and the maintainers understand this. Just need some examples 😉

This is where pragmatism takes over

I basically have fallbacks (like the big state object that takes the place of this and big let bindings that are basically imperative code) so that I can just get stuff done. As time goes on and I get better at cljs, I take the opportunity to make things cleaner.