This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-07
Channels
- # beginners (95)
- # cider (131)
- # cljdoc (12)
- # cljsjs (2)
- # clojure (209)
- # clojure-dev (1)
- # clojure-italy (3)
- # clojure-nl (10)
- # clojure-russia (37)
- # clojure-spec (19)
- # clojure-uk (182)
- # clojurescript (136)
- # cursive (28)
- # datomic (28)
- # editors (55)
- # figwheel-main (1)
- # fulcro (36)
- # hyperfiddle (12)
- # jobs (1)
- # jobs-discuss (55)
- # luminus (1)
- # mount (1)
- # off-topic (28)
- # onyx (18)
- # reagent (17)
- # ring-swagger (4)
- # rum (14)
- # shadow-cljs (22)
- # spacemacs (15)
- # tools-deps (16)
- # vim (26)
are there any dominant patterns/consensus in the clojurescript ecosystem for "CSS at scale"? Like, do we use Atomic Design, inline styles a la react, Atomic CSS, something different..?
learning CSS in depth for the first time along with reagent, meaning I'm not coming to the table with something I'm already familiar with
so, looking for direction. Seems like patterns of the object oriented lineage are all the rage in CSS right now 💤💤
one can reduce the amount of duplication in component CSS files by referring to common styles. Naturally not that easy in plain CSS but I would guess no one really writes plain CSS these days anymore...
this can lead to relatively big CSS file in the end footprint wise which is a drawback
by component styles, do you mean inline styling in the hiccup, or do you mean grouping your CSS into components
well it depends on how you like to build your components but with plain html example:
<div data-component="component-name">
<span>something</span>
</div>
and in CSS:
[data-component="component-name"] {
span {
font-weight: bold;
}
}
one doesn't necessarily have to use that way to group components but it's one way I've used in the past succesfully
that way the component CSS declaration for span
has a higher specifity than the styles defined within theme level where it would be just span { <styles here> }
and thus you can provide basic styling at theme level and override what's needed for component
right. lets you work on components in isolation, and lets components be the fundamental blocks of composition
web components provide us shadow dom which allows us to define style definitions in isolation in relation to rest of the DOM
Alright, well, I guess I'll just stick to webcomponent styling. That seems like both the path of least resistance (I really don't want to learn pattern libraries and atomic design) and the most compatible with reagent's philosophy. Thanks, @niklas.collin!
that has worked for me quite well, there are some problem areas but one can usually solve those individually case by case
and in my opinion, going the component way and thinking scales best in general when creating UIs
yeah. It's just too weird having 2 different units of composition between javascript and CSS
one way to handle that mess is to use garden css and inline your styles with the components
That's an interesting point right there. because I'm actually kind of sold on the idea that javascript should dynamically inject classes rather than styles, if for no other reason than j-unit tests target classes
so if you've got some cheap testing help, it'd be easier for them to write automation against explicit classes
but use just CSS. But I'm meaning you can have your CSS declarations in a separate file or you can have them within HTML file inlined within <style>
element
if you have a high volume site with a lot of expected full page refreshes (like, a news site) then you should NOT do the inlining
but if you have a webapp with users logging in once and then hanging on for the whole day then it really doesn't matter that much
what I'm currently working on is more of the latter and I went with a solution where the whole app, HTML, JS and CSS is embedded into the original HTML file which is transferred gzipped with HTTP. About 200kb in total, single HTTP request.
oh, I see. I mean that if the UI changes state, rather than capturing the change by changing the value of [{:style ...}]
, you change the value of [{:class ...}]
that way, the CSS can change the style and the j-unit tests can assert the difference
user clicks a button which will expand a div with some information, just add a class called visible
or whatever to the div when click happens. Handle rest in CSS
I have a case where I cannot get rid of the warning "every element in a seq should have a unique :key". I have reduced the problem to code snippet below. In the real problem the final line uses a function, which is why I need to use the cmd-panel3 approach so I can wrap the list of vectors returned in a vector with :div.wrapper at head. Ideas?
@poverholt I would guess the divs within wrapper are dynamic? Add keys to those
@poverholt do you get the same result if cmd-panel3
does this instead?
(into [:div.wrapper] '([:div "4"] [:div "5"] [:div "6"]))
the key warning is to optimize for performance in the reagent diffing mechanism, @poverholt. It's saying it wants a unique key on each component in a list so it can efficiently check to see if any of them have changed in subsequent diffs. If you aren't concerned about potential performance problems you can safely ignore the warning. Here's some further reading: https://stackoverflow.com/questions/37164091/how-do-i-loop-through-a-subscribed-collection-in-re-frame-and-display-the-data-a/37186230#37186230
weird that [:div.wrapper [:div "1"] [:div "2"] [:div "3"]]
would work but (vec (cons :div.wrapper '([:div "1"] [:div "2"] [:div "3"])))
wouldn't
I thought they'd be equivalent
^ sorry for spamming with incorrect syntax 😄
@idiomancy yeah but that is weird it behaves like that since the code he posted is executed before reagent does anything with it. Those functions are called as functions, not as reagent components
I wonder if the metadata is not applying correctly in the second case
@poverholt I agree with @manutter51 - maybe try the into version
yep or this ^
yeah, I hear you, but the return value is a sequence. it's the same if you just drop a (for [x stuff] [:div x])
@idiomancy there's a vec
call though so would be equivalent to (vec (for [x stuff] [:div x]))
I think
I think it's just a reagent thing
like vectors are the magic syntax for react elements
oh... I see... if you put it in a vector, it doesn't see it as a list of components, it sees it as a single component
TBH I find this stuff hard to get right around the fringes
here's the bit that checks for vector https://github.com/reagent-project/reagent/blob/9f2b492ff884a3068b3d03f63f8157259bf49ded/src/reagent/impl/template.cljs#L407-L415
(I think)
oh right now I get what is happening, mostly at least. I'm actually surprised that the first case doesn't cause a warning too
it creates something like this (not exact but structure should be representative):
[:div
[:div.top-line-return-value-dunno]
'([:div "1"] [:div "2"])]
now if one would assume the (top-line pres)
returns a single element then one could do:
(into
[:div]
(concat
[(top-line pres)]
(map cmd-panel (:cmd pres))))
that way one should end up with following structure:
[:div
[:div.top-line-return-value-dunno]
[:div "1"]
[:div "2"]]
now however depending on that the cmd-panel
elements actually are it might make more sense to add them to reagent as reagent components
if that's the case then one should not return [:div "1"]
but [some-component-fn]
which then renders the div
and I think if this is done then keys might be a good idea to keep react working quickly
I'm trying to package some javascript and having issues, could anyone take a look at my repo and tell me if they see anything wrong? https://github.com/colinkahn/deckgl-cljs
I deployed it to clojars using mvn deploy
, but when I use it in my project I get a vague error that says to check the file it was imported into. https://clojars.org/org.clojars.protocol55/deckgl
@danieleneal @niklas.collin @idiomancy @manutter51 Thanks so much. The with-meta worked! - not exactly sure why. Into did not help the problem, but I think it is cleaner syntax than what I had. Thanks.
if you're just looking for cleanliness, you could also do
^{:key (:name cmd)} (into [:div.wrapper] '([:div "7"] [:div "8"] [:div "9"]))
(defn cmd-panel4
[cmd]
(into [:div.wrapper {:key (:name cmd)] '([:div "7"] [:div "8"] [:div "9"]))))
^ is what I tend to use
I narrowed it down to the :global-exports
line, removing that makes it work. Are there any known issues with :global-exports
or is my setup just wrong? https://github.com/colinkahn/deckgl-cljs/blob/master/src/deps.cljs#L3
@colinkahn Did you include the error you received in the backlog?
I haven't posted a ticket but I can. Unfortunately the error is very vague, just saying that the file I'm importing the library into failed to compile (I'm using Figwheel, I could try reproducing without it though).
am i just missing a phone number parsing / formatting library in goog closure docs? that seems like something that would exist, given goog-libphonenumber?
i dont want the standalone version libphonenumber, mostly because it’s 400+kb optimized(!)
@lwhorton you can take the files here and put them on your classpath. they are written in closure JS so they are fully :advanced
compatible. https://github.com/googlei18n/libphonenumber/tree/master/javascript
I only use the java version so I'm not exactly sure how well the JS versions works though
@lwhorton adding onto that, there’s a cljsjs package for libphonenumber already: https://github.com/cljsjs/packages/tree/master/libphonenumber Looks like that will just pull in the lib, so any unused parts will be optimized out (I think)
Reagent seems to be easier (from a JS react user) than om/om next. But is reagent equivalent to Om/OmNext?
takamura: do you mean functionality / scope? re-frame wraps reagent to get closer to om/om-next in scope. I'm not familiar enough with either to compare functionality
@euccastro I mean more in terms of abstraction. Om next seem to use concepts more advanced than reagent (like using queries parsers mutations, etc)
Actually, I am familiar with ReactJs but not familiar with any clojure react library. I did some tutorials but I am still thinking in what to use
There is much less learning material for om next than there is for re-frame, which is a ui framework more comparable (imo) to om next than reagent.
If you're interested in the om next philosophy I'd recommend checking out fulcro, which has pretty decent documentation.
I usually recommend reagent/re-frame to newcomers because the learning curve is more manageable. Reading some docs from each before making your own decision doesn't hurt, though. :)
I do wish we had something a bit closer to the metal when it comes to React wrappers
and there's rum with citrus 😛 (sorry to give you one more problem): https://github.com/roman01la/citrus
that's much less used (I think?) than reagent/re-frame, though, so it might be harder to get help if you get stuck somewhere. all in all, I'd second @codonnell's recommendation