Fork me on GitHub

@juhoteperi re: feel free to ping me here if you need more info


I’ll try to reproduce on another machine too


@sb great that you found your solution! But I think that both @pesterhazy and I were really confused, both as to what your problem was, but also what the solution was… For your own sake, I think you should work on making your code examples smaller. I’m pretty sure that your problem did not involve charts in any way, I think it was really just concerning the reagent API, right? So remove all of the chart code for your examples. Also do it while you’re trying to find the problem on your own! I do this a lot - start off with a problem in a huge codebase where a 1000 things could contribute to the problem, then try to reproduce the problem in a much smaller codebase to narrow in and actually find out what’s wrong.


Remove everything that is irrelevant to the problem when asking for help, I think that’d increase the quality of the replies that you will get to your questions 🙂


I understand that your level of English is also a challenge, but that is maybe harder to solve 🙂 making your code examples smaller is something that you can do right away.


I will write down later (today). @reefersleep


Write what down?


I just want to explain what was the problem really, what I learnt from this and a little bit react. Quickly, I can say, the biggest problem was I tested the solution without reagent classes (just reagent, re-frame + re-frisk). I tried to create the smaller project: test with counter, because with stream.. or random numbers I can’t follow - debug what happens. Based on this I integrated the Google Chart code.. what I want to use (Mikes said to me.. that is the way, I started from a different viewpoint). I used a smallest line graph to this and I put the counter in the title (not in the graph really). So, that was mainly a task how to integrate the Google Chart library with reagent classes, because without this of course I can put the number there.. but because I render the chart at the server-side (not client side) therefore that wasn’t a good solution really (hiccup not refresh). I created that chart engine with D3/NVD3.. but that example was bad (as Mikes said to me.. works but .. not works with Google Chart). Therefore I would like to understand what is the problem really.. I do apologise for my not so accurate posts, next time I would like to do everything as you wrote down. 😉


I didn’t understand based on specifications how to use Reagent classes with atoms/ variables. But before this.. I thought I understand this. 🙂


I really thanks for your helps!! 👍💪


Sounds like I managed to describe to you - after you had already solved the task - how you solved the task 😄 That is, by narrowing down your problem. Maybe I’m really some kind of reverse clairvoyant?


Which seems like a really useless superpower 😛


Anyhow, thanks for the writeup. I’m uncertain of what the final product is - something that renders a chart that you desire serverside, or clientside? (I haven’t tried making charts myself yet, and reading create-class code with lots of js interop is not yet everyday stuff for me, I mostly read and write much simpler components : )

Yehonathan Sharvit15:09:13

A question about the internals of reagent: are there macros involved in the rendering of a reagent component or is it only done with functions?


you can use macros if that's what you mean - eg. for is a macro and very frequently used. But I don't think I understand your actual question.

Yehonathan Sharvit15:09:14

@noisesmith my question is about how reagent works: Does the reagent code that renders a component uses macros or not?


it would be hard to find clojure code that doesn't use macros


defn is a macro

Yehonathan Sharvit15:09:50

Let’s put it another way: is it possible to implement a react wrapper in pure javascript that renders components defined in hiccup-like syntax


it would be possible, yes


macros are just source to source transforms done by the compiler, they are never needed for functionality, only for human readability

Yehonathan Sharvit15:09:21

Do you know hiccup-like syntax is not popular in the javascript community?

Yehonathan Sharvit15:09:40

Would it be possible to use hiccup-like syntax in a react.js project instead of JSX?


You'd need to make something that reads that syntax...

Yehonathan Sharvit15:09:11

I’m asking all those questions because I’m preparing a talk about clojurescript for javascript developpers


so, hiccup literals work in cljs because they are valid data literals


they don't need macros because you can already declare data that way, it just happens to be that reagent (or hiccup, or other workalikes) knows how to translate that data into a dom


BBL - I need to go get coffee.


Reagent doesn't use macros to change hiccup style syntax to React elements, it is all functions


right, the hiccup "syntax" doesn't have a parser - it's just clojurescript data literals, plus a function that treats that data specially - in fact you can use reagent without data literals - it would be ugly and annoying but it would work


Where "use macros" means that Reagent doesn't create it's own macros which would be involved in this

Yehonathan Sharvit15:09:56

We could imagine to have something like ["div", "Hello World", ["div", "in js"]] in hiccup.js


that would be possible, with a function to preprocess it would be pretty easy I bet

Yehonathan Sharvit15:09:17

How would you compare it - in terms of elegance - with JSX?


I think react jumped ahead to JSX (a preprocessor/"macro")


Instead of using a declarative DSL first


With JSX comes significant tooling complexity


Not to mention mental overhead


A better solution would have been to come up with a DSL for createElement in JS (like hiccup), and then add an optional transformation for performance


I think people are also turned off React because of JSX at first - new syntax confuses people.