Currently, all tokens exported from Coda (apart from the duplicate ones) are defined here:
https://github.com/Devographics/entities/blob/main/tokens/pain_points/html_pain_points/new_pain_points.yml
Beyond the fact that a single huge list of 300+ items is harder to manage, there are many items which are simply not pain points, such as
https://github.com/Devographics/entities/blob/main/tokens/pain_points/html_pain_points/new_pain_points.yml#L2026
- id: webusb
name: |
WebUSB API
parentId: apis_capabilities
This is a browser API, and should be defined in this file (for example):
https://github.com/Devographics/entities/blob/main/entities/features/html_features/html_main.yml
As well as follow the same general structure as for example the Web Share API:
- id: web_share_api
webFeaturesId: share
name: Web Share API
needsTranslation: true
description: Exposes a mechanism for sharing content to various user-selected targets.
descriptionIssues: >
Issues related to the Web Share API for invoking the native sharing
capabilities of the device.
parentId: apis_capabilities
example:
language: js
code: navigator.share(shareData)
mdn: en-US/docs/Web/API/Web_Share_API
w3c: TR/web-share/
resources:
- url: https://web.dev/web-share/
title: Integrate with the OS sharing UI with the Web Share API
caniuse: web-share
tags:
- features
patterns:
- share api
- navigator\.share
In other words:
- Move to correct file
- Use underscores in the name, so
webusb -> web_usb_api (this helps with regex matching)
- Also do any renamings in Coda doc just to be safe, even though ideally we won't use it anymore.
- For backwards compatibility, add a
idAliases: [webusb] field
- Add
webFeaturesId field (in this case webusb)
- Maybe add description, code examples, mdn, w3c, etc. links, etc. (nice to have)
Because there are too many entities/tokens to deal with in one go, we can prioritize those that actually appear in the survey (Any pain point question -> All pain points -> Flat view -> find the items that look like actual APIs or features).
Currently, all tokens exported from Coda (apart from the duplicate ones) are defined here:
https://github.com/Devographics/entities/blob/main/tokens/pain_points/html_pain_points/new_pain_points.yml
Beyond the fact that a single huge list of 300+ items is harder to manage, there are many items which are simply not pain points, such as
https://github.com/Devographics/entities/blob/main/tokens/pain_points/html_pain_points/new_pain_points.yml#L2026
This is a browser API, and should be defined in this file (for example):
https://github.com/Devographics/entities/blob/main/entities/features/html_features/html_main.yml
As well as follow the same general structure as for example the Web Share API:
In other words:
webusb -> web_usb_api(this helps with regex matching)idAliases: [webusb]fieldwebFeaturesIdfield (in this casewebusb)Because there are too many entities/tokens to deal with in one go, we can prioritize those that actually appear in the survey (Any pain point question -> All pain points -> Flat view -> find the items that look like actual APIs or features).