These are chat archives for ractivejs/ractive

12th
Jul 2017
Joseph
@fskreuz
Jul 12 2017 03:03

does anyone else feel dirty using display: table?

@granmoe Nope. I occasionally use for shrink-wrap containers when inline-block doesn't cut it. Also use it with table-cell for vertical centering.

Joseph
@fskreuz
Jul 12 2017 03:10

has anyone given any thought to dynamic component css?

@evs-chris My thoughts on components is that after they're implemented (or released into the wild for reuse), they're treated as immutable. All possible outcomes (renderings and styles) are pre-defined. The consumer only has limited options, based on what was implemented. Essentially saying "this is what you can and can't do".

And the enclosing component should have nothing to do with how the embedded component looks like. Preserves integrity of the embedded component. The common cause of styling problems on our end is when people have this component, but want a slightly different color/style/font/theme. They end up defining styles on the enclosing component and passing it in rather than defining additional modifiers on the original component.
What happens after is a component that looks different on one part of the app, whose look cannot be carried over to a different part because the style was defined on the parent, not on it.
Joseph
@fskreuz
Jul 12 2017 03:15
TL;DR: I prefer my CSS fixed/pre-defined :D that's just me tho
Would be nice if CSS were able to interpolate against data like the template tho. That would be sufficient.
Chris Reeves
@evs-chris
Jul 12 2017 03:28
That's what I was thinking... Allow css to be a text-only template that used data attached to the constructor at extend-time
You could change the pre-defined vars before the first instance, allowing the component author to define things like accent colors that had defaults but could be overridden
Maybe even put a re-eval function on the constructor to allow post-render update
thinking about apps that have user selectable themes there
Joseph
@fskreuz
Jul 12 2017 03:34
Maybe it's a good time to allow css on instances/ per-instance styles for this to work without restyling entire families of components. :D
sort of like the function version of data.
Chris Reeves
@evs-chris
Jul 12 2017 03:41
I was thinking something like:
Ractive.extend({
  css: `.rootEl { background-color: {{bg1}}; color: {{fg1}} } .otherEl { color: {{bg1}}; background-color: {{fg1}} }`,
  cssData: { bg1: 'red', fg1: 'white' }
});
It might make more sense to use ${ ... } interpolators though and turn that into a function.
Joseph
@fskreuz
Jul 12 2017 03:42
:thumbsup:
Chris Reeves
@evs-chris
Jul 12 2017 03:43
Either way, I think it'd be ideal to have the vars be inheritable via prototype so that a component suite could be consistently themed easily
Joseph
@fskreuz
Jul 12 2017 03:43
How do you pass cssData when used on a template?
Chris Reeves
@evs-chris
Jul 12 2017 03:44
The other approach I've considered is moving css interpolation to a build step in the ractive bin
you'd have to do it ahead of time - Component.setCssVar('bg1', 'green')
or something along those lines
I don't think you could allow instance-specific css on a managed component
you'd have to do an extension
Joseph
@fskreuz
Jul 12 2017 03:46
Switch from component id to instance id for scoping ids?
Would print duplicate css on styles tho.
Chris Reeves
@evs-chris
Jul 12 2017 03:47
that side's actually not too hard... just use the instance guid for the additional css passed to the instance
can still use the constructors id(s) too
just no way to do that from the template e.g. <cmp ??? />
unmanaged components give you access to init params, but at that point, an extension is not really onerous
Chris Reeves
@evs-chris
Jul 12 2017 03:53
now that I think about it, maybe css templating is a bit too far
Joseph
@fskreuz
Jul 12 2017 03:54
:smile: there will be use cases for it.
Chris Reeves
@evs-chris
Jul 12 2017 03:54
oh definitely, but I'm thinking for that, just a function that is called in the context of the constructor and returns a css string would suffice
Ractive.extend({ css(vars) { return `.foo { color: ${vars.fg} }`; }, cssVars: { fg: 'green' } })
Joseph
@fskreuz
Jul 12 2017 03:58
Yup, that looks good. Also limits interpolation. Mustaches would make one think references and expressions are possible, which is probably overkill. :D
Chris Reeves
@evs-chris
Jul 12 2017 04:00
Yep, I'm having a hard time justifying the spin-up of a ractive instance just to process the css
keeping it runtime-ish doesn't exclude those who don't like or can't swing build steps
Chris Reeves
@evs-chris
Jul 12 2017 08:27
I have a working prototype of css functions, but are there any better names than cssVars, setCSSVars, and reapplyCSS?
cssVars is the object that is passed to the css function. setCSSVars does an assign to the existing object. reapplyCSS forces an update to the ractive style element .
cssVars is an init option, and the other two are static methods added to component constructors
perhaps cssVariables, cssData, or cssObject would be better?
Matt Granmoe
@granmoe
Jul 12 2017 13:48

"> does anyone else feel dirty using display: table?

@granmoe Nope. I occasionally use for shrink-wrap containers when inline-block doesn't cut it. Also use it with table-cell for vertical centering."

@fskreuz That wasn't me :-)

Joseph
@fskreuz
Jul 12 2017 13:49
Ooops :grimacing: That's actually for @evs-chris :D
I hate collapsed message layouts. Makes you scroll up to see the sender.
Would be nice if Gitter allowed a name per message.
Joseph
@fskreuz
Jul 12 2017 13:56
Looking into react-style frameworks, I notice that they have this requirement of keys on list items so the framework knows where the array items moved during update. How does Ractive handle this without putting this responsibility to the dev?
Chris Reeves
@evs-chris
Jul 12 2017 15:06
You have to use a shuffle set or a splice op if you want your items to move rather than just having their guts updated.
Joseph
@fskreuz
Jul 12 2017 15:10
Is shuffle based on a known algorithm? Trying to understand how it works by stepping through code, but a write-up would be a good start. :D
Chris Reeves
@evs-chris
Jul 12 2017 15:21
It creates a map of old index to new index using a comparator that defaults to identity.
You can also supply a property name for identity comparison or a function that returns whether or not the two given items are equal.
React's key is basically the pragma from #2947, and I've been leaning that way again.
Joseph
@fskreuz
Jul 12 2017 15:26
Ahh, now that makes sense. :thumbsup:
Chris Reeves
@evs-chris
Jul 12 2017 19:37
just to be sure I'm not off my nut here - components that extend components should apply css ids for all parents along the way, right?
meaning b extends a, a and b both have css, and b has a top-level div - the div should be <div data-ractive-css="{a-id} {b-id}">...</div>, right?
Joseph
@fskreuz
Jul 12 2017 19:39
Hmm...
Chris Reeves
@evs-chris
Jul 12 2017 19:40
not that I've seen many component extensions in the wild
it's usually just Ractive -> Component rather than Ractive -> Component -> SubCompnent
Joseph
@fskreuz
Jul 12 2017 19:41
Me neither. I only extend from Ractive. But I would think that approach is correct.
Chris Reeves
@evs-chris
Jul 12 2017 19:41
but if you're making a component suite, then it makes sense to do that to gather common style stuff in a base component
Joseph
@fskreuz
Jul 12 2017 19:42
Another way would be similar to scss @extend, you give the id to the parent, then combine it with their CSS.
Chris Reeves
@evs-chris
Jul 12 2017 19:43
cssIds are already forwarded through components that have a top-level component, so that elements within the inner component pick up the correct ids
combining css would get a bit crazy with transforms though, wouldn't it
Joseph
@fskreuz
Jul 12 2017 19:44
yes, that's what I was just thinking. the overhead of knowing which class has which subclasses.
Chris Reeves
@evs-chris
Jul 12 2017 19:45
I think I've got a reasonable solution for css templates with variables
Joseph
@fskreuz
Jul 12 2017 19:45
:tada:
Chris Reeves
@evs-chris
Jul 12 2017 19:46
I did have to fix id propagation so that subcomponents get their parent component css applied
I'll put up a PR in a bit to see if holes can be poked in it