TiddlyWiki / TiddlyWiki/MultiWikiServer
Testers needed
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 60
- Forks
- 16
- PR merge metrics
- No merged PRs in 30d
Description
Everything is done being converted to the new system. I need people to start kicking the tires and opening issues here for anything that doesn't work right or seems missing. Improvements to existing features and bug reports are both welcome.
Let's keep the react UI for now, as it is extremely simple to update. But please let me know what you think and where you could see improvements happening.
We should add this repo to the TiddlyWiki docs as well so it can get more exposure.
I'm done for now. I think this is everything I intended to do for the moment and I want to see what everyone else's feedback is.
The Admin UI
I work with React in most of my projects so it's something I'm familiar with and can easily keep in sync with the server as I make changes.
- The MUI component library abstracts away the details of HTML and CSS making it easy to declaritively make UI changes.
- The data goes between server and client using standardized POST requests and TypeScript interfaces to keep everything typed correctly.
- The server uses zod to validate incoming data and the routing system is flexible and hopefully intuitive.
The wiki API
The wiki routes follow the same routing flow, and the existing tiddlyweb API is still being used for now. Zod is used to validate all the path and query parameters.
The tiddler store functions that are called by the wiki routes have been rewritten to use prisma. I haven't tested everything but it should be working.
What's next
Syncer system could probably be improved
I'm thinking there should be ways to improve or replace the current syncer setup. The tiddler store in the browser is actually part of a synchronous rendering engine. The async components which keep that store updated with outside changes could be completely replaced. All that's required is that a consistent view of the store is available at any given moment for the rendering engine (the widget tree) to use.
Given that we're using sqlite, we have a number of options we could integrate from existing solutions. The only requirement is that it works well and integrates seemlessly with the recipe system. I feel like the current recipe/bag system is still lacking some features, and still has some undefined behavior that should be nailed down. Synchronized editing sessions and version history need to be improved, as I don't think the currently proposed system is sufficient.
Formatting recommendations
I want to stay pretty close to standard typescript formatting, but I'll happily consider recommendations for formatting the code.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names the React admin UI, wiki API, Prisma-backed tiddler store, SQLite, and syncer system, but no file or test to start from. Begin by reproducing a concrete missing or broken behavior in the converted system, then open a focused issue with reproduction details; no single completion condition is defined here.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, sqlite, typescript
- Domain
- backend, documentation, testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 18/100