BrianTakita.com P

Reactive Tag Graphs

reactive_tag_graph graph__tag__reactive
G graph graph tag tag graph->tag reactive reactive tag->reactive

Unique abstraction names

_: tags on the left, type on the right

product_id, selected_member_name, form_ctx


__: type on the left, tags on the right

id__product, name__member__selected, ctx__form

Use across all layers of the stack (frontend, services, api, database)

The abstraction has the same meaning independent of where it's used

What about css, url's, or filenames?

Composes with other rules such as SEO

- is analogous to _

blue-color, my-element-height, /posts/new-opportunities-for-you, app-config.json


-- is analogous to __

color--blue, height--my-element, /posts/you--new-opportunities, config--app.json

Ambiguous names requires mental modeling to build context

id -> of what?

customer_id -> easy to scan, no further thought required

customer_id__preferred -> tags make abstractions more specific

Reading Left to Right

customer_id__preferred


Initial scan of leftmost tag (type) makes it quicker to work with in code

Tags that add context can be placed on the right