This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-25
Channels
- # admin-announcements (5)
- # arachne (1)
- # beginners (29)
- # boot (36)
- # cider (110)
- # clara (1)
- # cljs-dev (3)
- # cljs-edn (14)
- # cljsrn (24)
- # clojure (63)
- # clojure-belgium (3)
- # clojure-dusseldorf (5)
- # clojure-greece (9)
- # clojure-russia (142)
- # clojure-sg (15)
- # clojure-uk (20)
- # clojurebridge (4)
- # clojurescript (58)
- # data-science (1)
- # datomic (37)
- # editors (2)
- # editors-rus (7)
- # emacs (1)
- # garden (31)
- # hoplon (3)
- # jobs-discuss (8)
- # keechma (86)
- # leiningen (1)
- # liberator (2)
- # mount (23)
- # off-topic (2)
- # om (18)
- # onyx (42)
- # planck (1)
- # quil (6)
- # re-frame (8)
- # reagent (3)
- # ring-swagger (1)
- # specter (4)
- # untangled (1)
Hey I’m wondering if there has been any unofficial best practice established for achieving pseudo selectors with garden inline at the component level (using reagent). So far from research it seems that the only way to do it is to use the :style tag in a parent div or component?
That’s correct. The only way to compose pseudo selectors in CSS is through an external stylesheet or styles within a style
tag.
Something that would be cool to build is a macro that could be used within components that compiles style information to a single external file. I’ve been meaning to find time to experiment with this, but haven’t yet.
I’m kind of hesitant to go down the road of building a large web app where <style> tags are being injected into the dom though, just “feels” wrong kind of
I know exactly what you mean. However, I can at least offer that it does work remarkably well.
And hopefully when such a macro exists, the refactoring and code cleanliness will be simple and straightforward.
have you been using <style scoped> to try and contain it a bit more and remove the need for class names to some extent on child elements ?
Yes, unfortunately the support for the scoped
attribute is still limited so as a fallback I’ve been using gensym
on classes for the root element of components to scope styles.
No problem. Let me know what kind of solution you go with. I’d be interested to hear what works well for you.
I’d like very much to roll inline styles as I feel thats moving more in the “right” direction and have seen a lot of compelling use cases with react
just trying to really get my ducks in a row and get a feel for how it’s going to look code wise before pitching it to my team
(defn component
[data owner]
(reify
om/IInitState
(init-state [_]
{:root (keyword (str (name :div)
(gensym ".unique")))})
om/IWillMount
(will-mount [_]
(om/set-state! owner :style
(css [(om/get-state owner :root)])))
om/IRenderState
(render-state [_ {:keys [root style]}]
(html
[root
[:style {:scoped "scoped"} style]
]))))
Yeah, I’ve done that so refactoring later when support for scoped
is universal is simple.
I like that I get to separate CSS almost entirely into the IWillMount
section. Then styles that rely on state become embedded in the HTML elements in IRenderState
. Which feels nice.
I see, yeah I will have to try coding the equivalent in reagent with some sort of similar abstraction for pulling in the css def, maybe even just an import or declaring it in the component file above the component itself
It hasn’t yet come in handy, but my initial reason for that was so that I style information is something that you can query from the component itself. It makes editing a single component entirely self-contained.
I’m still exploring as well, but this is what we’ve been building at my company so far and it has worked very well for us.
Oh really, well that’s great to hear, I’d definitely like to be able to do likewise, but there is some resistance on the team from those that are more accustomed to using less etc so it needs to be a compelling sell