Open mattpocock opened 3 years ago
I’ll just continually update this comment as I plod through and tag machines. Ignore the first few versions as I play around with the tags and how they might look/be structured. (Or jump in and tell me if you’d rather I took a different path if you spot me doing something that just isn’t going to work.)
Note: each tag is listed on a new bullet. I won’t hash-tag them as GitHub wants to use the hash to reference an issue.
state/parallel: form-input;
state/final: create-or-update-form
action/transition: form-input; create-or-update-form; authentication
action/assign: form-input; create-or-update-form
action/entry or exit: create-or-update-form; authentication
invoke: form-input; create-or-update-form; authentication
invoke/callback-pattern: form-input;
context: create-or-update-form;
transition/eventless: create-or-update-form;
transition/guarded: create-or-update-form;
Where-you’re-up-to note: authentication, working top-down from the alphabetical list in the folder structure (vs. how they appear on the page).
@mattpocock Have you thought any more about how you’ll implement tagging? Is it worth me building more of an object vs. just bullet-points? Feels like complexity is going to O(n^2)
, might as well think about how to get this right at the start.
Machines should have 'tags' relating to different XState advanced concepts, like 'nested states', 'actor spawning', 'invoked callback', 'guards'.
The tags should be shown on the machine's page, as well as in search results and on the home page.