handling the forest of "component ..."

[quimt]

As a framework is used more and more intensely, more components will be introduced and composed in various ways. Tags will then tend to be replaced by components, until the point where code starts looking like this:

"/":
  component OuterFrame(....):
    component PageTitle
    component PageSubtitle
    component AccountPanel(...):
      component ShoppingCart(...)
      component Promo(...):
        "promo text"
      component Orders(...)
    component MerchGrid(...):
      component MerchItem(...):
     ...
 

When coding at a high level of abstraction, the use of a component keyword becomes tedious and redundant.

One way of handling this might be to mimic some of how tags are handled and use a c as the disambiguator instead of the t for tags. Hence cCompX would always be understood as component CompX for any CompX. This might make the above kind of code easier to read, since the relatively unmeaningful keyword component is no longer at the front of every line:

appRoutes: "/":
  cOuterFrame(....):
    cPageTitle
    cPageSubtitle
    cAccountPanel(...):
      cShoppingCart(...)
      cPromo(...):
        "promo text"
      cOrders(...)
    cMerchGrid(...):
      cMerchItem(...):
     ...
 

[Ethosa]

sounds good. I'll think about it

[Ethosa]

maybe ease way is remove component keyword and just use component names?

but in this case developers shouldn't name component with HTML tag

appRoutes: "/":
  OuterFrame(....):
    PageTitle
    PageSubtitle
    AccountPanel(...):
      ShoppingCart(...)
      Promo(...):
        "promo text"
      Orders(...)
    MerchGrid(...):
      MerchItem(...):
     ...

[quimt]

That also seems good, and is in line with Karax' way of doing things. I would argue that sufficiently experienced developers wouldn't want to name components the same as HTML tags even if they could, because it makes code harder to read, maintain, etc.

Those who are new to HTML may be annoyed at unintended collisions, but if there were a helpful error message, perhaps suggesting a link to https://www.w3schools.com/Tags/tag_{{yourTagHere}}.asp, it would tend to be a meaningful learning experience that is worth the occasional extra compiler error.

I still like a small cue that signals whether I am looking at a component or a tag, but given that happyX lets us add the t disambiguator to any tag name already, and that I am already in the habit of 'tagging' all my tags like this, I don't think people like me would be bothered by your proposal.

[Ethosa]

so it solved

[Ethosa]

As a framework is used more and more intensely, more components will be introduced and composed in various ways. Tags will then tend to be replaced by components, until the point where code starts looking like this:

or this 👀:

<template>
  <OuterFrame ...>
    <PageTitle></PageTitle>
    <PageSubtitle></PageSubtitle>
    <AccountPanel>
      <ShoppingCart></ShoppingCart>
      <Promo>
        promo text
      </Promo>
      <Orders></Orders>
    </AccountPanel>
    <MerchGrid>
      <MerchItem></MerchItem>
    </MerchGrid>
  </OuterFrame>
</template>