This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (14)
- # boot (28)
- # chestnut (9)
- # cljsrn (18)
- # clojure (64)
- # clojure-conj (1)
- # clojure-dusseldorf (45)
- # clojure-finland (4)
- # clojure-gamedev (1)
- # clojure-greece (8)
- # clojure-italy (22)
- # clojure-russia (4)
- # clojure-spec (19)
- # clojure-uk (38)
- # clojurescript (49)
- # code-reviews (2)
- # component (12)
- # core-async (3)
- # cursive (3)
- # data-science (2)
- # events (4)
- # fulcro (394)
- # heroku (3)
- # hoplon (16)
- # immutant (11)
- # jobs (5)
- # lein-figwheel (1)
- # lumo (18)
- # off-topic (8)
- # om (11)
- # other-languages (1)
- # overtone (1)
- # pedestal (7)
- # portkey (62)
- # protorepl (1)
- # re-frame (40)
- # reagent (41)
- # ring-swagger (5)
- # spacemacs (5)
- # unrepl (5)
- # yada (12)
@juhoteperi re: https://github.com/reagent-project/reagent/issues/310 feel free to ping me here if you need more info
@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 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. 🙂
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?
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 : )
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.
@noisesmith my question is about how
reagent works: Does the reagent code that renders a component uses macros or not?
macros are just source to source transforms done by the compiler, they are never needed for functionality, only for human readability
Would it be possible to use hiccup-like syntax in a react.js project instead of JSX?
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
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
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
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