kees/grip
output.mp4
An XOR gate with inputs at
What's in each branch of this project?
Branch | Description |
---|---|
main |
Where all development occurs |
001-stateless |
A decent little clickable grid (bad on mobile) |
002-list-lookup-state |
Grid toggle is refactored to use state |
003-bool-array-state |
Grid state is improved |
004-control-panel |
Input panels for grid interaction |
005-ruleset |
Apply a stateful series of logic gates |
Develop on the project on any given branch:
npm i
npm run watch
open http://localhost:8280/
The project is not meant to be built manually but it can be done with npm run release
.
I am working on a unique CI/CD workflow using branches instead of releases. All development occurs either on main
or a local branch. A branch is pushed at any milestone which will publish IN PARALLEL to all other branches. I use numerical prefixes which is arbitrary but conveniently sorts chronologically.
Currently I need to work on custom formatting indices and page navigation, then the effect will work. I want a visitor to step through live builds to see the progress and if interested, read thoughts on them. Realistically the solution will be a canvas page that uses rewrite-clj
on publish and embeds live builds in an iframe.
For now, view the main branch here: hardly.link/projects/d02-grip/
View the loose initial roadmap
- π Section
- π Subsection
- Development goal
- βοΈ In progress
- β΄οΈ Completed and unreleased
- β Completed and released
What is this list formatting? Iβm trying out a style of list I wrote about adapting here. It's an informal and currently manual notation for managing projects that are too small to need a grand kanban deck.
- π Housekeeping
- βοΈ Add some notes
- β Basic information
- Mindset and goals
- βοΈ Add some notes
- π Important fixes
- βοΈ Mobile layout
- β
Basic statefulness
- β High-low state values
- β
Boolean array state values
- β Fix XY swapping
- β Fix integer coercion with interceptor
- π Schema/spec
- Introduce something for validation (I like malli?)
- π CI/CD
- β Branch or tag repo management?
- βοΈ Build workflow
- βοΈ Create post-build script
- β Normal build
- β Accept a string argument that will propagate
- β Either switch HTML refs to relative paths OR just watch reloads
- β Upload build to SPECIFIC path of S3 bucket, deleting
- β Upload index to SPECIFIC path of S3 bucket, file only
- β Invalidate CloudFront
- β
Integrate
bb
to start redoing the primitive versions in clj scripts - βοΈ Complete pagination
- βοΈ Create index page linking to all published pages
- β
Versions (e.g
003
) - Variants (e.g
003a
)
- β
Versions (e.g
- βοΈ Create back and next buttons
- rewrite-clj to add vector of all populated sorted branches to views and dynamically choose current +1 and -1
- βοΈ Create index page linking to all published pages
- π Further dom population
- Insert github link to repo branch
- Basic info "built from xxx in user/repo"
- Page title from branch name?
- Style index page
- β
Create github action
- β Detect some change (branch, tag)
- β Execute the post-build script with necessary data
- βοΈ Revise early published versions once workflow completed
- βοΈ Create post-build script
- π Malleability
- π Refine data transformations
- Introduce specter for incoming application of rules?
- π Prepare for data transformation
- β Introduce QOL form creation library (fork?)
- Explore alternatives for simplicity
- βοΈ Data in
- β Control panel
- β Basic actions
- Continue with basic input actions as needed
- Read from saved grid and ruleset: program abstraction
- βοΈ Data out
- β Single button status
- Side effects
- Save state and rules as accessible program
- Data transforms
- βοΈ Logic gates
- β
Basic unary &
$n$ -ary gates - XOR, XNOR
- β
Basic unary &
- Logic gate status lights, styling, diagrams
- βοΈ Logic gates
- π Refine data transformations
- π Evolution
- Stepwise re-render, time
- β Tick