commits
this implementation is so nasty, it's entirely vibe coded. But it does
work!
the bug we were facing was due to lack of understanding that `colVersion` also needs to be tracked alongside `dbVersion`. we also made some updates to the way the handshake happens for the protocol, introducing sync_request and having the server request changes from the client when it is ahead. The solution is entierly unoptimal right now, possibly with many duplication bugs and request (state tracking for the lastest version on the client side is particularly garbage), but it does work.
I'm also certain that there's code smells surronding authentication, up
to and possibly including overwriting existing keys in the
authentication table.
The v2 spec included in this commit has been implemented up to Phase 1:
Core Protocol. We will still need to implement authorization.
we moved filter state into it's own context so it can be changed and
accessed anywhere.
filter-context now handles it's own parsing, and changes are always
propagated through filter-text as the state. newText gets updated to be
filter text when in filter mode, and the side bar reacts to and changes
the filter text as well.
- mobile sync component
- greater bottom scroll length for mobile view
- use hamburger icon for sidebar trigger
- multiple rooms in sidebar
So now it's just one commit, whoops.
I implemented filtering, and now we're actually saving and querying tags
as json in sqlite which is nice.
I also implemented working_ids as an sql view, so that should continue
to work on TUI, but TUI is now falling behind on features compared to
js, which is good. I'm almost at the point of parity, though it's been a
long time since I've run the TUI version... The web version probably
works better now, given all the changes to the parser
I implemented little badges for both the selection and the fliter
contexts. However you can't edit them right now, only know that they're
triggered. Under the hood it's still all one command parser, which is
really nice.
Next I need to work on edit, and then saved filters.
starting to come together
I realized I'm going to have to seperate selection and filter state
And do actions based on that, some how show that different context
depending on which action is selected
- deployed to fly using a Dockerfile 🤮
- submit button
- scroll wheel action
- only add works currently
A couple hints to remind me what I'm doing
can compile both the react application statically so it can be served by
nginx
and then builds a docker container with nginx for easy deployment to
something like fly.io
I mean since it's static I could probably host it for free on a website
like netlify or something, but I still wanted a docker container for
now.
Notably I did have to move the generated javascript parser into the
mast-react-vite folder so that `buildNpmPackage` was scoped to the
mast-react-vite folder. I'm not sure how to get it working in a truly
monorepo style build working for it yet, but I'm not exactly inclined to
make it super shiny right now either.
this implementation is so nasty, it's entirely vibe coded. But it does
work!
the bug we were facing was due to lack of understanding that `colVersion` also needs to be tracked alongside `dbVersion`. we also made some updates to the way the handshake happens for the protocol, introducing sync_request and having the server request changes from the client when it is ahead. The solution is entierly unoptimal right now, possibly with many duplication bugs and request (state tracking for the lastest version on the client side is particularly garbage), but it does work.
I'm also certain that there's code smells surronding authentication, up
to and possibly including overwriting existing keys in the
authentication table.
The v2 spec included in this commit has been implemented up to Phase 1:
Core Protocol. We will still need to implement authorization.
we moved filter state into it's own context so it can be changed and
accessed anywhere.
filter-context now handles it's own parsing, and changes are always
propagated through filter-text as the state. newText gets updated to be
filter text when in filter mode, and the side bar reacts to and changes
the filter text as well.
So now it's just one commit, whoops.
I implemented filtering, and now we're actually saving and querying tags
as json in sqlite which is nice.
I also implemented working_ids as an sql view, so that should continue
to work on TUI, but TUI is now falling behind on features compared to
js, which is good. I'm almost at the point of parity, though it's been a
long time since I've run the TUI version... The web version probably
works better now, given all the changes to the parser
I implemented little badges for both the selection and the fliter
contexts. However you can't edit them right now, only know that they're
triggered. Under the hood it's still all one command parser, which is
really nice.
Next I need to work on edit, and then saved filters.
can compile both the react application statically so it can be served by
nginx
and then builds a docker container with nginx for easy deployment to
something like fly.io
I mean since it's static I could probably host it for free on a website
like netlify or something, but I still wanted a docker container for
now.
Notably I did have to move the generated javascript parser into the
mast-react-vite folder so that `buildNpmPackage` was scoped to the
mast-react-vite folder. I'm not sure how to get it working in a truly
monorepo style build working for it yet, but I'm not exactly inclined to
make it super shiny right now either.