This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # alda (4)
- # beginners (15)
- # boot (89)
- # cljs-dev (88)
- # cljsrn (75)
- # clojure (149)
- # clojure-belgium (16)
- # clojure-france (2)
- # clojure-greece (6)
- # clojure-russia (108)
- # clojure-spec (39)
- # clojure-taiwan (3)
- # clojure-uk (7)
- # clojurescript (70)
- # css (3)
- # cursive (17)
- # data-science (2)
- # datascript (7)
- # datomic (41)
- # dirac (3)
- # hoplon (12)
- # instaparse (1)
- # juxt (3)
- # lambdaisland (9)
- # mount (4)
- # off-topic (6)
- # om (71)
- # om-next (4)
- # onyx (22)
- # other-languages (56)
- # perun (15)
- # proton (6)
- # re-frame (32)
- # reagent (42)
- # specter (34)
- # spirituality-ethics (7)
- # tmp-json-parsing (5)
- # untangled (13)
- # vim (4)
- # yada (6)
@mhr: Notes in response: - Yes, "spreadsheet model" (javlin) is FRP. - re-frame tries to be just-enough FRP, but no more. - If you definitely want to use Datascript, then Posh might be a good fit for you.
DataScript is certainly a good database if you need "graph database" kinda queries. On the other hand, for a great many cases, a good old map is good enough.
This is a bit far-fetched but has anyone considered making reagent render clojure.xml instead of hiccup? I'm thinking it might be nice to be able to customize the hiccup parsing, e.g. parse a class but then use inline styles associated with that class.
reagent renders to react elements, so I guess what you would want is to add a react backend? But not sure why you want that
or am I misunderstanding?
right now: hiccup -> react elements my suggestions: hiccup -> customizable transform -> clojure.xml -> react elements
@martinklepsch: afaik, clojure.xml is only for clojure and not clojurescript.
@rohit: yeah, clojure.xml is more like an example of a more low level structure, the bits needed to render react elements from clojure.xml data wouldn't be hard though
@martinklepsch: so this maybe the code which converts from hiccup to react components: https://github.com/reagent-project/reagent/blob/master/src/reagent/impl/template.cljs#L287
@martinklepsch: i see the benefit of atleast the use case you present.
i guess you can also achieve that by having a map from class name -> style and then doing a lookup on that class name
@rohit: where would you do that lookup?
@martinklepsch: when you are creating that hiccup
right but then I'd have to do it on a per component basis & traverse nodes or traverse the entire tree y? There's no hook for this kind of thing
I'm not sure about applications of this besides the inline styles stuff but it feels like a generalization type thing that allows people to explore more weird ideas 🙂
@rohit: yeah, essentially that's it
its certainly not a big change but I guess you’ll have to convince the reagent maintainers about it
why would it only be for type-1 components?
@martinklepsch: for type 2/3 you aren’t really returning hiccup. you are returning a function or a class
right but these also use the hiccup transformation somewhere, no?
@martinklepsch: i’ve got a hack for your use case
Hi, each time I press the “enter” key my page reloads 😞 any idea how I can avoid that?
i think i avoided that enter key reload problem by not having any of my forms be actual
<form>s. but now i'm thinking there's probably a reason i shouldn't have done that. can anyone think of a reason why it's a bad idea to not use
Can anyone point me to a solution to a (very minor) annoyance? I'm working on an app with some params sent via URL string and routed with secretary and stored in a reagent atom (which is initialized to nil), and every time the code is recompiled via figwheel, it reinitializes the atom and I have to hit reload to get the values I want to test/mess with back in. I suppose I could hard code them, but I'm wondering if there's an obvious solution for this that I'm just not thinking of? :-). Thanks!