More CSS Types/Styles

[nathanhack]

First off, kudos on this library. When considering this library over vecty ... it was an easy decision. Vecty has created a fat layer making it hard to understand and brittle. Your lib feels like a much better amount abstraction and OMG you have examples and documentation (worth it's weight in gold)!

On to the feature request:
The CSS bit is great. However, there many more CSS types/styles out there. Since this library isn't about removing the need to understand how CSS is done, would you consider using a map[string]string instead of explicitly coding for each CSS type/style and value?

Thus the prop for the css would be a map like:

map[string]string{
    "display": "flex",
    "color":   "#444",
    ...
    }

[myitcv]

Thanks for the feedback @nathanhack - it's still very early days for myitcv.io/react but I'm hopeful the approach will stand the test of time.

The CSS bit is great

This is actually one area of myitcv.io/react that is very primitive in implementation terms. Much like the broader goal of myitcv.io/react, the idea behind properly typing the various CSS properties is to reduce compile time errors, make code transformations easier etc.

But as you can see from the cssGen template, they're not currently fully typed:

react/cmd/cssGen/main.go

Line 23 in ffe10c5

"FontSize": typ{"fontSize", "string"},

For now I've essentially fallen back to a code generated equivalent of map[string]string, per your proposal:

react/gen_css_cssGen.go

Line 13 in ffe10c5

FontSize string

The goal is ultimately to code generate the React elements from the HTML N spec. Similarly, the goal is to code generate the CSS types from the CSS N spec. Quite how code would interoperate between HTML versions is, I admit, an unknown. But it strikes me that problem is an easier one to solve than the cost of not having typed fields for HTML elements or CSS properties.

So what would this look like?

FontSize would be an interface type with corresponding concrete types that allow for the restrictions described here, i.e. allow me to specify a percentage, absolute size, computed size etc.

There's plenty to work out here of course. But once complete we would effectively have a Go type-based encoding of HTML elements and CSS properties.

For now I'd prefer to stick to my halfway-house of having code generated properties but all of the string type (which is equivalent to your proposal, minus the fact that the properties themselves need to have been defined). Which means we'll need to merge changes to cssGen in order to define additional CSS properties.

Please feel free to ping back here with any specific properties, or if you're feeling generous you can submit a PR. If you need any guidance on what's required to submit a PR (because that's not documented) please also ping back here.

[nathanhack]

For now I'd prefer to stick to my halfway-house.

I believe your position is more than reasonable. Something is frequently better than nothing. However, doing some of the CSS in a css file and other parts in code isn't really the best design for my projects.

However, I REALLY REALLY like where the CSS implementation is heading. I also would like to contribute to its success. Partly, because I'm using it in my projects; and because I believe this project has the better approach than others.

Given what your ultimate goal is, I personal wouldn't put any more effort into any of the CSS properties as they are currently. (And thanks for even entertaining the idea. :-) But let's not.)

I have only about 8-10 unique CSS types/properties that I need for my current project and I would like to add them to your repo.

Could you provide a few more concrete details? Maybe outline, a few more of the details as you see it implemented for the FontSize case. So that I could start working on it.

Also, have you given much thought how to handle the case where the CSS is independent of HTML elements such as @media?

[myitcv]

However, doing some of the CSS in a css file and other parts in code isn't really the best design for my projects.

This is a good point. I haven't (yet) given much thought to ways in which we could unify writing CSS in Go itself, or indeed whether that would even be a sensible goal. If we're going to the effort of generating types from the spec though, it wouldn't be so far fetched. We'd then need to come up with some sort of mechanism by which classes could be declared etc... definitely one to think about another day.

I have only about 8-10 unique CSS types/properties that I need for my current project and I would like to add them to your repo.

Great!

Could you provide a few more concrete details?

Sure, I'll pull something together when I get a moment.

Also, have you given much thought how to handle the case where the CSS is independent of HTML elements such as @media?

Nope. Very much falls into the same category as the class definitions etc - i.e. not thought much about it yet.

[myitcv]

Apologies @nathanhack I haven't gotten round to looking at this yet.