This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-20
Channels
- # adventofcode (8)
- # aleph (2)
- # announcements (10)
- # aws (5)
- # aws-lambda (2)
- # babashka (23)
- # beginners (23)
- # biff (9)
- # calva (4)
- # cider (8)
- # clj-kondo (21)
- # clojure (77)
- # clojure-boston (1)
- # clojure-dev (50)
- # clojure-europe (36)
- # clojure-gamedev (3)
- # clojure-nl (1)
- # clojure-norway (3)
- # clojure-spec (33)
- # clojure-uk (3)
- # clojurescript (22)
- # core-async (3)
- # cursive (10)
- # datahike (18)
- # datalevin (1)
- # datascript (9)
- # deps-new (21)
- # emacs (11)
- # events (1)
- # graphql (11)
- # guix (26)
- # java (7)
- # jobs (3)
- # lsp (12)
- # malli (6)
- # pathom (33)
- # pedestal (3)
- # polylith (15)
- # reagent (5)
- # releases (3)
- # remote-jobs (1)
- # scittle (9)
- # sql (27)
- # tools-build (9)
- # vim (7)
Hi there, trying to find a way to save hiccup like code in database and render it from there. e.g. I have info-field, where I'd like to be able to format stuff or add elements, tables, lists etc. This I'd like to save this to the database as a string. My problem is, that I'm not able to render the string afterwards, it gets html-escaped and displayd as the given string, but i dont want: [:h1 "Hello world"] I'd like to have Hello world (cannot simulate h1 here, but I think you get what i mean) Can you give me a hint, how to render it?
https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml As the name says, this is dangerous
The above works only if you save HTML as a string. For Hiccup, you can serialize it as EDN or Transit before storing and deserialize upon retrieving so you get a proper Hiccup vector and not a string.
Also note that you won't be able to make that Hiccup use any CLJS code without hassle.
I.e. in plain code you can write stuff like [:button {:on-click #(...)} "Submit"]
, but it won't get serialized properly. Best you can do is [:button {:id :submit} "Submit"]
and then attach the onClick
handler dynamically.
Given that, I'd reconsider the whole approach. If it's possible, it would be much better to have a registry of possible elements and their settings and then use IDs or whatever from that registry when storing the current configuration in the DB.