robinweser / elodin Goto Github PK

A plugin that covers everything concerning colors. Especially a uniform output format.

(see docs/pages/repl)

encode/decode

In order to provide useful help to the user, we need to have proper error messages for every possible error thrown.

In order to use Elodin with ReasonML, we need to have a proper ReasonML generator with types and everything.
For now we might just render to bs-css.

Right now, only a subset of all pseudo classes / elements are allowed.
In order to fully support all use cases, we want to expand to all.

This applies to both @elodin/generator-css-in-js and @elodin/generator-reason.

We want to validate the comparison and add more abilities to it as well.
Especially dynamic conditions might be interesting.

view Box {
  [$withPadding] {
    paddingLeft: 10
    paddingRight: 10
  }
}

We should have a deterministic way of resolving shorthand/longhand properties.

The simplest idea would be: Longhands > Shorthands

As we only have a couple of shorthands and they're all just 1-level shorthands this would be fine.

We need a way to enable hard value validation even for dynamic values.
This can be achieved in two different ways:

• generating typings (TypeScript)
• adding runtime validation (devMode only?)

To reduce complexity of style definitions and passed dynamic values, we might want to introduce some logical functions.

if

if($variable trueValue falseValue)

This function accepts a dynamic boolean value and returns different values whether its true or false. It can also be nested.

view Box {
  paddingLeft: if($withPadding 10 0)
  paddingRight: if($withPadding 10 0)
}

fallback

fallback($variable fallbackValue)

This function is similar to if but rather than having a boolean variable with 2 hard-coded options it acts as an fallback value if the variable is not defined.

view Box {
  color: fallback($color red)
}

Probably use rimraf

For example, output same color format for all values.

In order to correctly generate variant maps, we need to make sure that class names with variants are applied in a deterministic order.

We should always apply variants in the order they're defined.

We need a way to distinguish dynamic values from theme values in order to support static extraction with theme values.
We can achieve that leveraging:

• CSS Values
• Passing a theme during compilation
• Having a naming convention

In order to support shorthand properties, we need a deterministic way to resolve them.
Maybe we should look at how React Native does it.

We could also have a plugin that expands shorthand properties in a deterministic way.

Note: Shorthand properties are only possible with single values e.g. padding: 10 due to the enforced limitation in Elodin. Once the value changes for different longhand values, so have to be used instead.

We can simplify and reduce the generated code by quite some size doing a dynamic extraction of modifiers on runtime.
We should check how it affects performance though.

We need to escape reserved keywords or it won't compile. Thanks to @sgrove for the following list https://gist.github.com/sgrove/fa05fafc6448c1cdda541e6474f2f264

Right now it is not possible to have nested dynamic values such as:

view Box {
  [@after] {
    padding: $padding
  }
}

We need to document several things:

• Language Syntax / Features
• Generators
• Setup
• Properties
• Types
• Plugins