# Clay Retrospective

## The Good

* allowing maximum flexibility in component design
* standardized editing interfaces across components
* style variations!
* page templates were a good idea (but needed better organizational ux)
* simplified permissions structure was a good idea
	* with friction for certain changes
* render plugins was a pretty good idea, but could be done better with a stricter api
* megabundler was good (for this specific use case)
* "User has edited this recently" message 
* synched fields (entities) was a good idea, needs an easier way to figure out keys
* bootstrapping was good in the beginning (e.g. when building new sites from scratch), but cannot be maintained (should use actual db backups instead)
* simplified page history was better than granular versioning
* claycli was generally good and useful
	* needed better error handling, non-http API (e.g. to do stuff with db dumps)
* simple-list and complex-list were generally good UX, could be better
	* simple-list should just be an array of strings
	* complex-list could have variations
		* cards
		* text w/ primary selection (same as current simple-list)
		* table-row
		* table-column
* magic-button was good, but even better with tooltips

## The Bad

* components got too complicated and large (should have been split into much smaller reusable pieces, like Vue/React components)
* unidirectional component references prevent a lot of functionality
	* composition at the app layer is slow, use a db instead
	* graaaaaph db with a caching layer would be best
* page vs layout was never clear
	* should have used page templates + allowed much less flexibility in their composition and editing (i.e. should have not had "layouts" as a separate concept from "page templates")
* component sunsetting + conversion was unsolved
* no unified style guide contributed to component duplication
* meta/head components were never understood properly
* invisible component lists were underutilized
* kiln / edit mode components were a bad idea, they should have been baked in
* publishing: url generation and publish flow had too many restrictions, was too abstract for end users ("what will my url be?")
* indexing / feed generation / elastic implementation was brittle and overcomplicated
* spaces was a brittle solution to the problem of layouts
* component bookmarks was a brittle solution to the problem of re-referencing
* ux was not designed mobile-first
* terrible accessibility outside of individual forms
* no true multi-user editing / realtime support / offline support
* single admin api key rather than per-dev api key generation
* split wysiwyg required a WHOLE lot of code, next time do content-list from the start (and find a way to embed components inside the wysiwyg itself)
* pubsub only worked client-side (need to know the context in ALL environments, e.g. by using a graph)
* amphora craps out if components don't exist (better handling of error states across the board, including handling of model.js errors)
* "dynamic pages" were implemented weirdly, didn't make use of express's built-in param stuff
* lack of amphora documentation
* poor test coverage

## The Ugly

* components should be single-file vue components
	* public-facing stuff utilizing server-side rendering
	* allows rich SPA interfaces
	* edit-facing stuff uses config.js
* multi-site config and styling isn't worth the hassle, isn't something a single implementation of the cms should solve for
	* site/global config should all be editable in the UI, not on the filesystem
* schema.yml should be a config.js (allows sane defaults + dynamic configuration), a combination of [this idea](https://github.com/clay/clay-kiln/issues/1310) and things like babel.conf.js/postcss.conf.js/jest.conf.js
* instead of state snapshots, use proper CRDT with much more granularity than just the component level
	* this allows for multi-user and realtime editing, as well as real offline-first support and history
* build the entire backend around eventbus + push rather than state setting + pull
* multi-lingual support / localization must be a first-class citizen
* user data and interaction feedback must be baked in from the start
* types of content: page (contains metadata, "layout" stuff, publishing logic), component, entity (might actually be able to do proper component back referencing in a graph db)
* have a universal solution to pubsub (e.g. by updating information using the graph)
* expand the clay menu more (it should be the centralized place for dashboard-y plugins)
* component logic (model.js) should be able to trigger messages to users when run client-side (for errors, warnings, etc)