not sure if the electric compiler supports that kind of dynamic dispatch, but the "obvious" implementation would be: • declarePortal : creates an atom, watches and invokes its value (if truthy) • to use the portal, set the atom to an (e/fn) that renders what you want • in (e/on-unmount) clear the atom

or an a lower level, use electric-dom2/with?

(d/with (.-body js/document)
  ; portal content here
)

doing this to the body element might be a bad idea, but if you create a wrapper you'll be writing to from only one location maybe that works?

(binding [dom/node js/document.body] ...)

@U797MAJ8M isn't that's what dom/with does?

Thanks for the input. I tried out the binding approach before posting, since that’s how the root node is mounted. The compiler complains.

I do it in several places, but iirc it's a bit picky yeah

dom/with has some extra sauce that I don't understand, but the description suggests it does what @U06B8J0AJ needs

(defmacro with
  "Attach `body` to a dom node, which will be moved in the DOM when body moves in the DAG.
  Given p/for semantics, `body` can only move sideways or be cancelled. If body is cancelled,
  the node will be unmounted. If body moves, the node will rotate with its siblings."
  {:style/indent 1}
  [dom-node & body]
  `(binding [node ~dom-node]
     ; wrap body in a constant frame, so it can be moved as a block
     (new (e/hook hook node (e/fn* [] keepalive ~@body))))) ; todo remove

dom/with sounds exactly like the ticket

Gonna try it out, thanks

No dice with with unfortunately, same error (`Failed to execute 'insertBefore' on 'Node'`) I’ll explain what I’m trying to do: global notifcations, where they are rendered near the root of the DOM, whereas the originators sit deep in the DOM. I see two alternatives: 1. Set up an atom, chuck up notifications as the atom is modified. Downsides: stateful, have to build an API, and customizations need to be covered by that API. Upsides: Possibly, notifications are automatically cooperative with regards to each other (hide the rest when there are more than three, etc.) 2. Find a way to portal the notfication to the notification container. Downsides: seems hard to do. Upsides: Notifications can be constructed locally, no need for an API.

yeah that error is what I mean by picky. I think you have to move the parent component of the "portal" around so that there's no dom elements after it or something

or wait a few hours, it looks like incremental is landing very soon and might just fix it outright

tailwind is honestly great

having tried basically everything over the last decade (css modules, css-in-js, BEM, sass/less, etc.) I can happily say that tailwind lets me just stop worrying about styles

I agree. We’re using Tailwind, and it would have to be something truly spectacular for us to choose anything else. But, all of us are also comfortable working in code. But with Tailwind, that is true regardless of the programming language: to get leverage, your UX person needs to be in the source files.

Tailwind

I’ve enjoyed https://github.com/green-coder/girouette