InNumbers component interface

[umbobabo]

Representation for an In numbers component

This is related to the issue about moving away from the Layout component

[adgad]

Suggested change

	numberLabel: string
	number: string

Should we keep the field name consistent with BigNumber?
(Incidentally I was wondering if it should be a number rather than string, but looks like BigNumber is also a string!)

[umbobabo]

The idea of using numberLabel is because I was leaving number available in case one day we will have a proper number: number, similarly to here we may have a date: Date.

If we want to communicate consistency/relations perhaps we should do this:

interface Number extends Node {
        number: string; << Still this is confusing to me
        description: string;
}

interface BigNumber extends Number {
       type: "big-number";
}

interface InNumbers extends Parent {
	type: "in-numbers"
	children: [Heading, Number, Number?, Number?]
}

but I wonder if this become a slippery slope towards some kind of coupling hell

[umbobabo]

@adgad On second thought, the likelihood to need a number as number seems very low, so we can go with your suggestion and same perhaps for the date in the Timeline PR. At then end, as UI representation, the need of have better types it's small. In the long term though we may have issue to automatically associate for instance a datePicker in Spark to a field that is a string instead of a proper date, that kind of problems.

[adgad]

👍 I guess because we haven't had any validation till now in the CMS, it's very likely that we have existing timeline dates that aren't dates, big numbers that aren't numbers etc.

In the long term though we may have issue to automatically associate for instance a datePicker in Spark to a field that is a string instead of a proper date, that kind of problems.

yeah i can see this being useful with schema-generated components in the future, and being able to have validation in the CMS as well!

[umbobabo]

it's very likely that we have existing timeline dates that aren't dates, big numbers that aren't numbers

Yep. The options are:

1. Use the label number as a string in the new In Numbers component and use date as a string in the new Timeline component

• Pros: consistency with existing components
• Cons: It's confusing and it will prevent us one day to have proper number as number and date as Date and we may end-up in even more confusing choices like numberAsNumber: number

2. Use label for fields that are free string, Editorial can really put whatever they want there

• Pros: avoid future breaking change or increase of what seems unideal/confusing naming convention
• Cons: lost in consistency with existing nodes

IMO and this is also for @elpopova and @todor-videv1 perhaps, part of this topic is about which future do we see for the Content Tree as a document? Is it just for a UI with a bunch of strings or shall it evolve to something that machine should better understand too. I'm raising it because this is in some form related too

[debugwand]

would keeping it to a generic thing like value help for future modelling for simple types (as opposed to data structures)? e.g. Number.value, SimpleThing.value. Or a bit more specific like text for strings.

[umbobabo]

Thank you @debugwand. I think this is a very good suggestion. It's already applied for Text here.

Potentially, we could use value and not having a breaking change even if we move towards what I mentioned here

[umbobabo]

Eventually, we could have something like...

interface Number extends Node {
        value: number; 
        number: string; 
        description: string;
}

interface BigNumber extends Node {
      type: "big-number";
} && Pick<Number, 'number', 'description' >

interface InNumbersNumber extends Node {
      type: "in-numbers-number";
} && Pick<Number, 'value', 'description' >

interface InNumbers extends Parent {
	type: "in-numbers"
	children: [Heading, Number, Number?, Number?]
}

... but we may not get any particular value to tight to a single Number node at this stage, perhaps we can keep them separated as they are in this PR and use value that will still permit us in the future to merge the types without a breaking change if we desire to do so

[umbobabo]

Heading it's not mandatory and we need to support ImageSet

Suggested change

	children: [Heading, InNumbersNumber, InNumbersNumber?, InNumbersNumber?];
	children: [Heading?, ImageSet?, InNumbersNumber, InNumbersNumber?, InNumbersNumber?];

[umbobabo]

We agreed with @adgad to use BigNumber instead of this (FE may need to be reviewed because styles used by big number)