Closed eric-burel closed 1 month ago
Run & review this pull request in StackBlitz Codeflow.
Thanks! For the record I think the alternative would be extending the "tutorial" collection, allowing more fields in it upon config. The main advantage is that it would be typesafe (but maybe it can also be done with "custom" using an ambient type somehow), and maybe extending a collection may have more benefit than just adding fields (though I don't know that). But it feels more complex while adding a "custom" dict is trivial codewise and should be far enough for the listed use cases.
extending the "tutorial" collection, allowing more fields in it upon config
Allowing users to add custom fields in root of the metadata could cause conflicts with possible future built-in metadata fields. Having this separate custom
option makes sure we don't introduce new fields that accidentally overrides user's own custom fields.
All in the title: a
custom
record on each configuration unlocks user-land features where we need to associate metadata to a specific entry:It should be future proof in the sense that even if a feature is later brought to TutorialKit core, users will just remove their custom code when updating, but their app won't break.
Having it inherited could be relevant for some custom fields (author name), weird for others (publication date) : I feel that inheritance is still more convenient than setting custom fields on every tutorial? Also will inheritance proceed to a deep merge or not?