Add RFC 067 Prismic API ID casing #117
Conversation
rfcs/067-prismic-api-ids.md
Outdated
| Whereas this isn’t a problem: | ||
|
|
||
| ``` | ||
| const { someProperty } = data; // <-- ✨ |
rcantin-w
changed the title
| SliceMachine makes these snake_case by default but allows this to be overridden easily in the GUI - we've done this fairly consistently although a couple of reusable content types have been given singular API IDs – `card` and `collection-venue`. I don't think there's any mileage in updating everything to snake_case since *none* of them are in that format currently. I'm not sure if we should try to update to `cards` and `collection-venues` or just live with those as they are? | ||
| SliceMachine makes these snake_case by default but allows this to be overridden easily in the Graphical User Interface (GUI) and to-date we have made *all* of them kebab-case, so there probably isn't a good case for changing these to snake_case now. | ||
|
|
||
| A couple of reusable content types have been given singular API IDs – `card` and `collection-venue` – should we consider changing these two to `cards` and `collection-venues`? |
There was a problem hiding this comment.
If the effort level is low, I think it would be nice, so might be a question of weighing time/effort? With the migration script, is this something we can consider doing easily?
There was a problem hiding this comment.
Creating the new (pluralised) types and migrating the content should be straightforward. I think the riskier part would be finding where the old (singular types) are linked from and updating those too. e.g. where a card is used on a page, we'd need to link it to the new version of the card
There was a problem hiding this comment.
Migration doesn't allow for overwriting, right? We always have to re-create a new document?
There was a problem hiding this comment.
I'm not sure what I was thumbs-up-ing there, but when we migrate we can modify existing documents rather than creating new ones
There was a problem hiding this comment.
Nice, that'd be great if it worked for IDs
|
|
||
| SliceMachine makes these snake_case by default but allows this to be overridden easily in the GUI - we've done this fairly consistently although a couple of reusable content types have been given singular API IDs – `card` and `collection-venue`. I don't think there's any mileage in updating everything to snake_case since *none* of them are in that format currently. I'm not sure if we should try to update to `cards` and `collection-venues` or just live with those as they are? | ||
| SliceMachine makes these snake_case by default but allows this to be overridden easily in the Graphical User Interface (GUI) and to-date we have made *all* of them kebab-case, so there probably isn't a good case for changing these to snake_case now. |
There was a problem hiding this comment.
👍
Let's consider this a documented decision and keep an eye should new content be created to ensure it's kebab-cased!
There was a problem hiding this comment.
Actually, quick thought, what about changing the decision to camelCase to reduce the amount of different casings we use?
There was a problem hiding this comment.
…or snake_case so that they're aligned with what we're going to (have to) go for with the Slice API IDs?
There was a problem hiding this comment.
Are these IDs used in our code/will cause TS pain?
There was a problem hiding this comment.
They aren't used as TS variables, no (they are currently kebab-case and that would already have been a problem for use in JS). They can only be used in quotes when querying Prismic.
There was a problem hiding this comment.
Right! So snake_case works too 👍
| ## Slice IDs | ||
| Prior to our use of SliceMachine, we gave our Slices camelCased IDs. However, SliceMachine requires that Slices have snake_cased IDs (it doesn’t let you override it in the GUI). When we migrated to SliceMachine we updated the Slice IDs in the [code](https://github.com/wellcomecollection/wellcomecollection.org/blob/main/common/views/slices/index.ts) and [type](https://github.com/wellcomecollection/wellcomecollection.org/blob/main/common/prismicio-types.d.ts) files that it generates to be camelCased in order to be able to use our existing code consistently. But each subsequent change to the Slice through SliceMachine will revert the IDs to snake_case and we have to remember to override it back to camelCase in several places across these two files. For newer Slices we have kept the default (snake_case) ids rather than override them to camelCase. | ||
|
|
||
| I don’t think we deal directly with the Slice IDs. Instead, we send all of them (in [a `components` object](https://github.com/wellcomecollection/wellcomecollection.org/blob/main/common/views/slices/index.ts#L5-L29)) along to SliceMachine, so the linting problems mentioned above don’t arise. As such, I propose that we move to using snake_case for all Slice IDs. |
There was a problem hiding this comment.
Agreed. Since it gets overwritten every time, we don't need to revert camelcasing anywhere do we?
☝️