These are chat archives for japgolly/scalacss

27th
Mar 2015
David Barri
@japgolly
Mar 27 2015 01:00
Thanks for all that info!
This will require some thought... Changing it so that multiple stylesheets can be added (addToDocument()) independent of each other is one thing.
Changing it so that each style adds just itself to document seems crazy to me. That means that every single time a style is referenced, it needs a check, variable and a potential side-effect.
The latter seems crazy to me. A performance hit for no real gain.
The former on the other hand should be ok.
David Barri
@japgolly
Mar 27 2015 01:10
a dynamic "CSS sink" which would put the generated CSS in the place where the user wants it. […] this allows individual style modules to define styles when needed and they would be appended to the CSS automatically
therefore libs could have their own ScalaCSS definitions without knowing how they end up in the actual HTML document, nor would they need access to the "top level" style object
Yeah but that's exactly what we have.
Style modules just add their styles onto some register. The register can come from anywhere and the module doesn't care where.
You can build up libs without knowing how they end up in the actual HTML. So far so good.
I think this is the part where dissatisfaction starts → The way to do this is to make shared styles classes, and include them in a parent.
David Barri
@japgolly
Mar 27 2015 01:16
Styled reusable components would then need to be passed that class in order to use it, and so the style becomes a dependency which seems better than depending on a singleton object when the values can actually change.
There's been a bit of a hyperbolic response to how to do reusable styles. This is a library, not a framework so you can think of it as tools instead of a template. I'm not so sure the tools are the problem, I think this might be an issue of guidance in how to use the tools effectively (and constraint/guard rails).
I think the best thing to do is start writing some code to demonstrate our issues and goals. Let's collectively put together a bit of code that demonstrates reusable styles in resuable react components.
David Barri
@japgolly
Mar 27 2015 01:24
( @ochrons you had many good ideas - would you mind raising issues so they aren't forgotten?)
David Barri
@japgolly
Mar 27 2015 06:19
Well this is new :D /bench
| Without:    886,595
|    With:  2,669,668
|Increase:  1,783,073 (+201%)

| Without:    175,392
|    With:    514,198
|Increase:    338,806 (+193%)
Triples the output size ha! Well it's easily measurable now.
Otto Chrons
@ochrons
Mar 27 2015 07:23

Changing it so that each style adds just itself to document seems crazy to me. That means that every single time a style is referenced, it needs a check, variable and a potential side-effect.

Not the way I see it. It would just register itself just like it does now, but the Register would output the result into the document right away instead of collecting them internally

David Barri
@japgolly
Mar 27 2015 07:29
Wait so you don't mean when the styles are access, you mean when they're first created?
Otto Chrons
@ochrons
Mar 27 2015 07:29
yes, at creation time
so functionality would be about same as now, but order of things would be different, first set the sink, then create styles, instead of first creating styles and then "sinking" them into the doc
and you'd still need that "global" stylesheet importing all other stylesheets, so that the objects are actually initialized and in correct order, too
but the lib code could use the styles without knowing the global style object
David Barri
@japgolly
Mar 27 2015 07:31
Oh right. I get you. What is the reason or benefit of that?
It saves the dev having to type addToDocument() but is there more?
Yes! Deterministic initialisation order is important :)
Otto Chrons
@ochrons
Mar 27 2015 07:32
right now, the class requirement prevents the lib to access its own styles
if it can be object then the lib can use styles directly
David Barri
@japgolly
Mar 27 2015 07:33
Using a class instead of an object models reality if those styles are configurable though. The class would be a (single) dependency to the component and then it's business as usual.
Otto Chrons
@ochrons
Mar 27 2015 07:35
or alternatively use the global registry to also store the stylesheet instances and the lib could request the instance from there
right now I have this inverted dependency in my super simple Bootstrap lib,
object Bootstrap {

  // shorthand for styles
  @inline private def bss = GlobalStyles.bootstrapStyles
David Barri
@japgolly
Mar 27 2015 07:38
Is the rest of that code online somewhere where I can peruse it?
I'm looking at that and I'm thinking well object is the problem no?
What do you think about having class BootstrapStyles and passing it in to components that need it?
1) Does it work (cos it fits my mental model)
2) Even if it works, are there impracticalities that make it unpleasant to do so?
Otto Chrons
@ochrons
Mar 27 2015 07:41
1) it would work, but
2) it would be impractical, because component users shouldn't concern themselves with stylesheets
I pushed the version of SPA tutorial containing ScalaCSS integration
it's there on the master branch since it works ok :)
of cooz I need to update the doc and clean stuff up, too
might as well switch to gitbook at this point
David Barri
@japgolly
Mar 27 2015 07:44
If component users use a component that needs styles, I'd argue that they might not want to deal with it but the situation is that they're depending on it to be there. Like not everyone wants to deal with SBT but if you want a working build you have to have it. Convince me otherwise (seriously)!
Otto Chrons
@ochrons
Mar 27 2015 07:44
but the styles are part of the component
David Barri
@japgolly
Mar 27 2015 07:45
I could see that argument more if you say that they will never need to modify the underlying styles of that component. Is that the case?
Otto Chrons
@ochrons
Mar 27 2015 07:45
only because ScalaCSS requires them to be installed in the global scope, they need to go around the long way
David Barri
@japgolly
Mar 27 2015 07:45
+1 agree
Wait it's not a ScalaCSS thing right, you'd get that with normal React too
Otto Chrons
@ochrons
Mar 27 2015 07:45
it's the same as saying "you are using 'btn btn-danger' in your component, so it should be supplied by the user of the component"
David Barri
@japgolly
Mar 27 2015 07:45
Or probably they'll just tell you in the readme to include a special .css file
But it does :D
They just make it the devs problem verbally outside of code, no?
Bootstrap even recommend that each project select modules and use a custom compilation instead of the big monolithic thing
Wait - that could be automated better (which is your point right?)
Otto Chrons
@ochrons
Mar 27 2015 07:48
I'm not talking about bootstrap specifically, but React components that need CSS styles
IMO the style is part of the component
David Barri
@japgolly
Mar 27 2015 07:48
Yeah I agree with that
It's simple when that component's style is blackbox, but what happens when you want to allow customisation of its style?
Otto Chrons
@ochrons
Mar 27 2015 07:50
yes, that is another (related) issue, that won't work with the current object approach
David Barri
@japgolly
Mar 27 2015 07:51
Is it the situation of non-customisable styles that you're more focussed on now?
Otto Chrons
@ochrons
Mar 27 2015 07:51
nor the regeneration issue I mentioned earlier
well, right now I'm just trying to make the SPA tutorial sensible in its use of ScalaCSS :)
so it wouldn't give Wrong Ideas to devs
but thinking ahead, I believe the modularization, customization and regeneration are also issues we should tackle
David Barri
@japgolly
Mar 27 2015 07:53
Yeah totally agree :) The problem is we have tools now but we don't know how to use them effectively. I think we all agree that the modularity issue needs change but it's hard to work out how to solve it
Otto Chrons
@ochrons
Mar 27 2015 07:54
and if you solve one of the aforementioned issues, it might make solving another one much harder :)
so it's better to take a holistic view on solving all of them at the same time
because it'll require some architechtual changes
David Barri
@japgolly
Mar 27 2015 07:55
My thoughts exactly :D
Hey cool that you're thinking of moving to gitbook
They've got an online interface but it doesn't live-render with syntax highlighting
The offline setup I've teased out, does live-render with syntax highlighting.
It's a pretty cool setup. you can even run my bin/book-dev in this project just to get a feel for if you like the setup or not
Otto Chrons
@ochrons
Mar 27 2015 07:57
ok, I'll copy your setup in that case :)
David Barri
@japgolly
Mar 27 2015 07:57
go for it :D
The only thing I might change about my setup is the way I handle my gh-pages branch
At the moment you'll see I have a /book prefix to my github url
You can get rid of that by doing your gh-pages branch differently
Otto Chrons
@ochrons
Mar 27 2015 08:02
ok, I'll check how it would work out
but now it's out last day in Lapland so time for some more :snowboarder:
David Barri
@japgolly
Mar 27 2015 08:02
sweet enjoy it dude! have fun
Otto Chrons
@ochrons
Mar 27 2015 08:03
I try not to break anything :stuck_out_tongue_closed_eyes:
David Barri
@japgolly
Mar 27 2015 08:06
don't break anything!! breaking body parts is not fun!
Matt Hughes
@matthughes
Mar 27 2015 17:34
is StyleA not a TagMod?
ah I forgot the import japgolly.scalacss.ScalaCssReact._ import
Matt Hughes
@matthughes
Mar 27 2015 18:00
One thing that I do miss from html/css days is having an editor that highlighted the difference between style code, structural code, etc
it all just looks the same
now
maybe we can come up with a new operator for styles
We have < for tags, ^ for attributes
V for styles!
then we just need to invent something for >