inherited systems

[amitu]

Currently we have a feature called inherited. (look at that syntax, how far have we come!). Say if a component is defined like this:

-- component my-color:

-- ftd.text: Text
padding.px: 20
border-width.px: 10
color: $inherited.colors.text-strong
background.solid: $inherited.colors.background.step-2
border-color: $inherited.colors.border-strong

-- end: my-color

It refers to $inherited.colors for example, and it can be passed to any of parent of this node, e.g.,

-- import: fastn-community.github.io/saturated-sunset-cs

-- ftd.column:
colors: $saturated-sunset-cs.main

-- my-color:

-- end: ftd.column

You can see a detailed example in this blog post.

Problem

We currently do zero compile time checks on these. Doing a compile time check for call stack is hard. Compilers have access to source AST trees, but not to call stack, which is a run time property, and it is call stack the decides what inherited values are going to be.

So this is a fragile feature. If you remove an argument from one of the ancestor components, very far away from the code where inherited is defined, this component can break. Also we have issues if same inherited variable is present in more than one place in the ancestry, and what if they have different types?

Further because we cant do compile time checks, IDEs will not be able to code completion on it either.

Not awesome.

Solution: "inherited systems"

We already have concept of systems. Systems can be thought of global aliases, each system has a name, and the name is global (which itself can be considered a problem, what if two systems end up picking same global name, or what if you have variables / modules with name clashing with a system, we are working towards a package name based system, instead of alias based system), so system imports (global system name, or tomorrow package name), are magical, you import something, but something else is "provided". What you are trying to import acts as an interface, and the "provided" module must implement this interface.

Now what you get when you refer to say ds which is system alias for design-system.fifthtry.site package, is decided by what you have put in FASTN.ftd, but what if we allow the call tree to overwrite them? E.g. a parent can say:

-- import: fastn-community.github.io/saturated-sunset-cs

-- ftd.column:
provide-system ds: saturated-sunset-cs

-- my-color:

-- end: ftd.column

Here we have used provide-system ds, meaning we are basically saying, in this hierarchy, to all the children of this ftd.column, when they refer to ds, the system alias, they will receive not the value specified in FASTN.ftd, but the saturated-sunset-cs module.

Now the component definition would look like this:

-- component my-color:

-- ftd.text: Text
padding.px: 20
border-width.px: 10
color: $ds.colors.text-strong
background.solid: $ds.colors.background.step-2
border-color: $ds.colors.border-strong

-- end: my-color

Note that we are using the $ds instead of $inherited.

Now the compiler can do complete type checking. When the component my-color is being type checked, we can ensure that $ds.* is as per the ds system, which is always design-system.fifthtry.site. And the caller, when it uses provide-system ds: saturated-sunset-cs, we can again ensure that saturated-sunset-cs is "compatible" with ds (meaning both has same symbols exported, by same name and same type).