... inference for components.

[siddhantk232]

Let's say I want to create a wrapper component around the design system's heading-large component such that I get a button to copy the link to that section.

-- component: heading-large-id
<all-the-headers-that-can-be-passed-to-heading-large>

-- ds.row

-- ftd.text: 🔗
$on-click$: <left-as-unimportant>

-- ds.heading-large:
<manually-pass-the-headers-from-heading-large-id-component-here>

-- end: ds.row

-- end: heading-large-id

This is cumbersome. We should support this usecase as it's pretty common to compose components on top of existing components in the frontend world (there are so many articles on higher order components).

Here's the syntax I suggest:

-- component: heading-large-id
<any-other-custom-header-decl>
... ;; THIS IS NOT A PLACEHOLDER BUT A VALID SYNTAX

-- ds.row

-- ftd.text: 🔗
$on-click$: <left-as-unimportant>

-- ds.heading-large:
... ;; THIS IS VALID SYNTAX

-- end: ds.row

-- end: heading-large-id

The compiler will figure out the header that ds.heading-large has declared and will add them to the heading-large-id component. If multiple components exist then heading-large-id will have the union of those headers. Here's an example:

-- component: one
caption title:
string id:

-- ftd.row:

-- ftd.text: component one: 
-- ftd.text: $one.title

-- end: ftd.row

-- end: one

-- component: user
caption title:
string email:

-- ftd.row:

-- ftd.text: $user.email

-- end: ftd.row

-- end: user

-- component: one-user
...

-- ftd.column:

-- one:
...

-- user:
...

-- end: ftd.column

-- end: one-user

The above is a syntax sugar that will be processed by the compiler to:

-- component: one
caption title:
string id:

-- ftd.row:

-- ftd.text: component one: 
-- ftd.text: $one.title

-- end: ftd.row

-- end: one

-- component: user
caption title:
string email:

-- ftd.row:

-- ftd.text: $user.email -
-- ftd.text: $user.title

-- end: ftd.row

-- end: user

-- component: one-user
caption title:
string id:
string email:

-- ftd.column:

-- one: $one-user.title
id: $one-user.id

-- user: $one-user.title
email: $one-user.email


-- end: ftd.column

-- end: one-user

design system has a lot of components that accept so many headers and this feature can be a god send for someone who wants to create wrapper components.

[siddhantk232]

I wonder where else can we use ... for inference? Zig has anonymous structs that I also want to bring to fastn.

[siddhantk232]

I'll leave this one open too. Not sure which one I like better. On one hand, I like https://github.com/orgs/fastn-stack/discussions/463 as it's immediately clear by looking at the inherit header that it's a wrapper component. But, I think ... can be generalised and used in other places where the context supports it and it's also less typing (less typing is arguable).

[amitu]

My key problem with ... is ... is typically used to omit things, and in code snippet etc it will cause confusion as if we mean to omit things or if it this syntax.

Also things ... are sigil only syntax, and hard to search, e.g., what do you call it? A keyboard based syntax is easier to search.

Taste wise also I find the code snippet you shown a little cryptic, non obvious.

Also its -- component <name-of-component>: and not -- component: <name-of-component>, unless you are asking for that syntax (which we have considered and rejected in the past).

[siddhantk232]

I agree. ... is not that great.

[siddhantk232]

Also its -- component : and not -- component: , unless you are asking for that syntax (which we have considered and rejected in the past).

That's a mistake. Idk why I always write components definitions like that. Why did we reject this btw?

[amitu]

Why did we reject this btw?

Consider: -- integer foo: 21. How will -- integer: foo work, where do I put the value?

[siddhantk232]

Closing this in favor of https://github.com/orgs/fastn-stack/discussions/463