e7e04da9 Changed the field type catalog to separate structure from validation
ref https://linear.app/ghost/issue/BER-3794/members-manage-their-own-custom-fields-in-their-account
The catalog answers two questions that are usually asked by different people. What
parts a field type has — an address has six, and the last of them holds a country
code — is what anything drawing a form needs. What counts as a valid value is what
the server needs when someone submits one. Both were declared together, built out
of zod, so asking the first question meant importing the second.
Measured through Portal's own build, with the import actually used: taking the
whole catalog costs seventeen and a half kilobytes gzipped and puts zod in the
bundle. Taking the structure alone costs a hundred and seventy-seven bytes and
puts none there. Ghost's server enforces the rules and can afford them; Portal
only draws inputs, and it loads on every page view of every themed site. Asking it
to carry a validator it will never run, to find out that an address has six parts,
is the wrong trade.
So the structural half now stands alone and imports nothing. A renderer that wants
it gets the types with it, rather than hardcoding part names as strings and hoping
they match. Anything needing both halves still imports one place; the split is
about what a bundle pays for, not about where the catalog lives.
The two cannot drift, because the rules are now built from the structure rather
than declared beside it: an address's parts are stated once, and the schema for
each is looked up from that statement. A part added without a rule, or a rule
without a part, fails to compile.
Splitting them also emptied something. A field type used to carry a map of its
parts pairing each name with both its declared type and its rule, because the two
were needed in different places and there was nowhere else to state the type. The
type is stated in the structure now, and nothing reads that map any more, so it
goes and takes the last of the coupling with it: a field type is a kind and a
rule, and what it is made of is described elsewhere. ae9b4a69 Changed the field type catalog to separate structure from validation
ref https://linear.app/ghost/issue/BER-3794/members-manage-their-own-custom-fields-in-their-account
The catalog answers two questions that are usually asked by different people. What
parts a field type has — an address has six, and the last of them holds a country
code — is what anything drawing a form needs. What counts as a valid value is what
the server needs when someone submits one. Both were declared together, built out
of zod, so asking the first question meant importing the second.
Measured through Portal's own build, with the import actually used: taking the
whole catalog costs seventeen and a half kilobytes gzipped and puts zod in the
bundle. Taking the structure alone costs a hundred and seventy-seven bytes and
puts none there. Ghost's server enforces the rules and can afford them; Portal
only draws inputs, and it loads on every page view of every themed site. Asking it
to carry a validator it will never run, to find out that an address has six parts,
is the wrong trade.
So the structural half now stands alone and imports nothing. A renderer that wants
it gets the types with it, rather than hardcoding part names as strings and hoping
they match. Anything needing both halves still imports one place; the split is
about what a bundle pays for, not about where the catalog lives.
The two cannot drift, because the rules are now built from the structure rather
than declared beside it: an address's parts are stated once, and the schema for
each is looked up from that statement. A part added without a rule, or a rule
without a part, fails to compile.
Splitting them also emptied something. A field type used to carry a map of its
parts pairing each name with both its declared type and its rule, because the two
were needed in different places and there was nowhere else to state the type. The
type is stated in the structure now, and nothing reads that map any more, so it
goes and takes the last of the coupling with it: a field type is a kind and a
rule, and what it is made of is described elsewhere. 9a8918c4 Changed the field type catalog to separate structure from validation
ref https://linear.app/ghost/issue/BER-3794/members-manage-their-own-custom-fields-in-their-account
The catalog answers two questions that are usually asked by different people. What
parts a field type has — an address has six, and the last of them holds a country
code — is what anything drawing a form needs. What counts as a valid value is what
the server needs when someone submits one. Both were declared together, built out
of zod, so asking the first question meant importing the second.
Measured through Portal's own build, with the import actually used: taking the
whole catalog costs seventeen and a half kilobytes gzipped and puts zod in the
bundle. Taking the structure alone costs a hundred and seventy-seven bytes and
puts none there. Ghost's server enforces the rules and can afford them; Portal
only draws inputs, and it loads on every page view of every themed site. Asking it
to carry a validator it will never run, to find out that an address has six parts,
is the wrong trade.
So the structural half now stands alone and imports nothing. A renderer that wants
it gets the types with it, rather than hardcoding part names as strings and hoping
they match. Anything needing both halves still imports one place; the split is
about what a bundle pays for, not about where the catalog lives.
The two cannot drift, because the rules are now built from the structure rather
than declared beside it: an address's parts are stated once, and the schema for
each is looked up from that statement. A part added without a rule, or a rule
without a part, fails to compile.
Splitting them also emptied something. A field type used to carry a map of its
parts pairing each name with both its declared type and its rule, because the two
were needed in different places and there was nowhere else to state the type. The
type is stated in the structure now, and nothing reads that map any more, so it
goes and takes the last of the coupling with it: a field type is a kind and a
rule, and what it is made of is described elsewhere. 240ef625 Changed the field type catalog to separate structure from validation
ref https://linear.app/ghost/issue/BER-3794/members-manage-their-own-custom-fields-in-their-account
The catalog answers two questions that are usually asked by different people. What
parts a field type has — an address has six, and the last of them holds a country
code — is what anything drawing a form needs. What counts as a valid value is what
the server needs when someone submits one. Both were declared together, built out
of zod, so asking the first question meant importing the second.
Measured through Portal's own build, with the import actually used: taking the
whole catalog costs seventeen and a half kilobytes gzipped and puts zod in the
bundle. Taking the structure alone costs a hundred and seventy-seven bytes and
puts none there. Ghost's server enforces the rules and can afford them; Portal
only draws inputs, and it loads on every page view of every themed site. Asking it
to carry a validator it will never run, to find out that an address has six parts,
is the wrong trade.
So the structural half now stands alone and imports nothing. A renderer that wants
it gets the types with it, rather than hardcoding part names as strings and hoping
they match. Anything needing both halves still imports one place; the split is
about what a bundle pays for, not about where the catalog lives.
The two cannot drift, because the rules are now built from the structure rather
than declared beside it: an address's parts are stated once, and the schema for
each is looked up from that statement. A part added without a rule, or a rule
without a part, fails to compile.
Splitting them also emptied something. A field type used to carry a map of its
parts pairing each name with both its declared type and its rule, because the two
were needed in different places and there was nowhere else to state the type. The
type is stated in the structure now, and nothing reads that map any more, so it
goes and takes the last of the coupling with it: a field type is a kind and a
rule, and what it is made of is described elsewhere. 9fecc4cd Changed the field type catalog to separate structure from validation
ref https://linear.app/ghost/issue/BER-3794/members-manage-their-own-custom-fields-in-their-account
The catalog answers two questions that are usually asked by different people. What
parts a field type has — an address has six, and the last of them holds a country
code — is what anything drawing a form needs. What counts as a valid value is what
the server needs when someone submits one. Both were declared together, built out
of zod, so asking the first question meant importing the second.
Measured through Portal's own build, with the import actually used: taking the
whole catalog costs seventeen and a half kilobytes gzipped and puts zod in the
bundle. Taking the structure alone costs a hundred and seventy-seven bytes and
puts none there. Ghost's server enforces the rules and can afford them; Portal
only draws inputs, and it loads on every page view of every themed site. Asking it
to carry a validator it will never run, to find out that an address has six parts,
is the wrong trade.
So the structural half now stands alone and imports nothing. A renderer that wants
it gets the types with it, rather than hardcoding part names as strings and hoping
they match. Anything needing both halves still imports one place; the split is
about what a bundle pays for, not about where the catalog lives.
The two cannot drift, because the rules are now built from the structure rather
than declared beside it: an address's parts are stated once, and the schema for
each is looked up from that statement. A part added without a rule, or a rule
without a part, fails to compile.
Splitting them also emptied something. A field type used to carry a map of its
parts pairing each name with both its declared type and its rule, because the two
were needed in different places and there was nowhere else to state the type. The
type is stated in the structure now, and nothing reads that map any more, so it
goes and takes the last of the coupling with it: a field type is a kind and a
rule, and what it is made of is described elsewhere. 438f332e Changed the field type catalog to separate structure from validation
ref https://linear.app/ghost/issue/BER-3794/members-manage-their-own-custom-fields-in-their-account
The catalog answers two questions that are usually asked by different people. What
parts a field type has — an address has six, and the last of them holds a country
code — is what anything drawing a form needs. What counts as a valid value is what
the server needs when someone submits one. Both were declared together, built out
of zod, so asking the first question meant importing the second.
That costs sixty-five kilobytes gzipped, of which about six hundred bytes are the
catalog and the rest is zod. Nothing tree-shakes it away, because the declarations
are zod schemas evaluated when the module loads. Ghost's server enforces the rules
and can afford them; Portal only draws inputs, and it loads on every page view of
every themed site. Asking it to carry a validator it will never run, to find out
that an address has six parts, is the wrong trade.
The structural half now lives on its own and imports nothing. Reading it costs two
hundred and sixteen bytes gzipped rather than sixty-five thousand, and a renderer
that wants it gets the types with it rather than hardcoding part names as strings.
Anything needing both halves still imports one place; the split is about what a
bundle pays for, not about where the catalog lives.
The two cannot drift, because the rules are now built from the structure rather
than declared beside it: an address's parts are stated once, and the schema for
each is looked up from that statement. A part added without a rule, or a rule
without a part, fails to compile.