Fork me on GitHub
#reagent
<
2021-04-22
>
Richie14:04:49

(defn modal [& {:keys [bg-render fg-render]}]
  (if-not fg-render
    [bg-render]
    [:div
     [bg-render]
     [:div.modal.is-active
      [:div.modal-background]
      [:div.modal-content
       [:div.box.is-clipped
        [fg-render]]]]]))
Is this bad for performance? Instead of toggling the “is-active” class on the modal I’m toggling the modal div in or out of existence. The “modal” class comes from http://bulma.io.

p-himik14:04:44

It's definitely worse than toggling display or visibility or moving the whole modal off screen. But it's alright if you don't have very complex contents that take a noticeable time to render. Also, your approach won't work properly for something that needs to maintain its own state. Just as an example Bokeh plots/documents maintain their own WebSocket connection. The have to be disposed of in a completely different way - just removing the DOM node will lead to all sorts of errors.

Richie14:04:40

Ok, interesting. I’m using re-frame so the idea that the ui is derived from the app state is what’s in my head. I haven’t been thinking of components as things with substance. It sounds like I’m throwing away my fg-render component as a substitute for better control flow logic.

p-himik14:04:54

I don't see how

(when show-component?
  [component])
is better than
[:div {:style (when-not show-component? {:display :none}}
  [component]]

Richie14:04:14

You don’t have to know about html or css in the first case.

p-himik14:04:36

That's a very leaky abstraction you're treading. ;)

Richie14:04:55

I don’t have a background in html or css. That’s going to influence how I solve the problem. I’m still trying to learn the best practices and develop a mental model for what’s really happening. i.e. How much work is happening behind what I’m asking reagent to do.

Richie15:04:48

You mean that I’m coupling the thing that provides fg-render to whether or not it should show?

p-himik15:04:18

I'm afraid the best, first, and foremost practice in frontend development is to learn the basics. And only then build on top of those abstractions. Right now you're at the top of a very high tower: Reagent -> (via CLJS) -> React -> DOM + JS/HTML/CSS. Without knowing at least the basics of the underlying components, it's would be incredibly hard to achieve something.

p-himik15:04:57

> You mean that I’m coupling the thing that provides fg-render to whether or not it should show? No, that doesn't bother me at all.

Richie15:04:31

Sorry, what’s the leaky abstraction?

p-himik15:04:25

Writing frontend code without dealing with HTML and CSS at all.

Richie15:04:45

I’m not trying to avoid html or css. However, if there’s an alternate way to solve the problem then I’m might do that first. And then like here, I’ll wonder if I don’t have the best practice.

Richie15:04:34

Anyways, thanks for the feedback!

simongray07:04:49

Gonna second @U2FRKM4TW here. When doing web frontend stuff, you should always look for a solution first in CSS, then HTML, then whatever stuff is outputting your HTML and CSS. If you approach it from the other end, chances are your frontend will be buggy, slow, and lacking accessibility. Usually the idiomatic CSS or HTML solution is more simple too.

Richie14:04:57

Ok, thanks. I’ll approach it with a “html/css first” mindset.

👍 3
athomasoriginal16:04:11

If you’re using React (Reagent) then I would recommend checking out portals. They were designed for scenarios like this. Of course, I may be making assumptions about what you have/have not done and for this I apologize! 🙏

Richie20:04:31

Thanks! I haven’t looked at portals yet so I’ll check that out. I appreciate the suggestion.

afleck21:04:54

i second the portal suggestion, the one time that i have used them i was pleased with how well they worked