Yeah so the metadata solution is the best I can come up with

There is no intrinsic difference between a function that returns a vector, a function that returns a function that returns a vector, a function that returns a map (the possible reagent components) and any other functions

The only ways to tell the difference is if you mark them

(with-meta function 'component) is one way to do that, but tbh I don't see a situation where a higher order function needs to make that distinction

(you can always call the function and check if the output looks like a component , but that might not be desirable)

I think that's what reagent.impl/reagent-component? Does

@mf, :ref (fn [el] (some-> el .click)

@mf, as to your other question, I'd reconsider what you're trying to do

can't you legislate that hof can only take components?

Thanks for the feedback @emccue and @pesterhazy. The use case I have is that in the real-world hof is a data-grid component that renders content that is supplied to it in table cells. The content supplied to the component can be either other sub-components , or just standard functions that produce string output.

@emccue Ideally I would not require the consumer of the data-grid component to have to identify the type of content with meta-data - although it is an interesting idea.

I guess one thing I could do is always wrap the supplied content in a "wrapper" component:

(defn wrapper-component [f]
  [:div (f)])

;; higher order function
(defn hof [f]
  [wrapper-component f])

(defn my-component []
  [:div "I'm a compnent"])

(defn not-a-component []
  "hello I'm not a component")

;; I want `my-component to be invoked with ()'
(hof not-a-component)

;; I want `my-component to be invoked with []'
(hof my-component)

you can't tell a function returning a string from a function returning a vector without claling them

@pesterhazy If you did call them, could you then use reagent/reagent-component? to determine if they are a component?

I don't think so

My brief exploration with reagent/reagent-component? suggests that this can only be used from within a component

(defn ^boolean reagent-component? [c]
  (some? ($ c :reagentRender)))

I think the component has to be rendered before it is recognisable as a component by reagent-component?

well there's a difference between the data structure returned by your fn and the "component" or "backing instance", a javascript Object you don't usually get into contact with much in Reagetn

if you create a Form-3 component, that would probably satisfy reagent-component? (haven't checked though)

@pesterhazy yes I think reagent-component? only works with mounted components:

(defn my-component []
  (reagent/create-class
   {:reagent-render
    (fn []
      [:div "hello world"])})))

(reagent.impl.component/reagent-component? [my-component]) ;; => false

try with round parentheses

same result

then you're probably right 🙂

ok cool, thanks for your help

I've stared a new Wiki page listing resources for learning Reagent as well as for more advanced topics: https://github.com/reagent-project/reagent/wiki/Links-and-Resources

prompted by @timothypratley latest blog posts by the way

Please add your favorite links!

Yeah nvm, I looked at the source code you are right

Hi! I'm quite new to reagent/react, but I have a question about dynamically updating a text box's value attribute. Not getting an answer on SO, so... http://stackoverflow.com/questions/41732520/reagent-doesnt-re-render-on-first-transition-of-ratom

@klozhur, there a couple of things going on there so it's hard to tell what the problem is

it would help if you could isolate the problem further

You should probably always set the value property (React doesn't like switching between controlled and uncontrolled components)

you probably also shouldn't be reading the DOM using dom/children, but that may not be related to the issue

my-droplist should mention the props in the inner fn (form 2 rookie mistake: https://github.com/Day8/re-frame/wiki/Creating-Reagent-Components)

why don't you swap! the ratom in on-change?

you usually need to do that so that users can type into the input box

an alternative is to use an uncontrolled component, but that's only useful in special cirumstances https://facebook.github.io/react/docs/uncontrolled-components.html

Thanks, I'll take a look. The reason I don't set value on nil atom: I wanted to allow both free text input, and list-click override which could then be further edited freely. So, I'd need to reset the atom to nil after overriding the textbox, lest it interfere with subsequent free editing. The weird thing is that, after a second selection, the textbox updates as expected.

@pesterhazy, does dom-walking interfere with react, do are you advocating against it for another reason?