mirror of
https://github.com/zkldi/Tachi.git
synced 2026-09-26 17:07:58 +03:00
zk
e363bd2532
* docs: migrate from mkdocs to mdbook - Rename old mkdocs docs/ to old-docs/ for reference - Set up new docs/ with mdbook (book.toml + src/ tree) - Mirror full nav structure from mkdocs.yml into SUMMARY.md - Add Justfile-docs with docs-serve, docs-build, docs-check, docs-install recipes - Import Justfile-docs from root Justfile - Rewrite .github/workflows/docs.yml: build step uses taiki-e/install-action to install mdbook, split into separate build + deploy jobs, PR builds run the check step too * ci(docs): pin actions to SHAs, install mdbook via release binary * ci(docs): install mdbook from apt instead of curling a release binary * dev: replace mkdocs python stack with mdbook in dev image * ci(docs): apt only works on Debian; restore release binary install for Ubuntu CI * docs: fix duplicate file entries in SUMMARY.md * docs: remove docs-install recipe * docs: remove site-url from book.toml to fix asset loading * dev: install mdbook from upstream release binary, not Debian apt The Debian package (0.4.x+ds) strips bundled font assets, leaving the built site without fonts/fonts.css. Use the upstream tarball (same as CI) so the theme is complete. Handles x86_64 and aarch64. * docs: vendor mdbook tarballs in dev/mdbook/, install from there Dockerfile.dev uses COPY + tar to install the right arch at build time. CI extracts the x86_64 tarball directly from the checkout. No network access required for either — and no stripped-fonts Debian package. * fix: unwritten
33 lines
1.3 KiB
Markdown
33 lines
1.3 KiB
Markdown
# Parsing Import Processing Info
|
|
|
|
The ImportProcessingInfo array returned from our
|
|
importing process is unwieldy to work with. We are interested
|
|
in what it has to say, though.
|
|
|
|
This step converts that array into data we use
|
|
in successive score import steps.
|
|
|
|
!!! info
|
|
Because the logic for this is essentially just one
|
|
loop, it does not get its own file in `score-importing/`.
|
|
|
|
Instead, it is defined inside `score-import-main.ts`.
|
|
|
|
*****
|
|
|
|
## Output
|
|
|
|
| Property | Type | Description |
|
|
| :: | :: | :: |
|
|
| `scoreIDs` | Array<string> | The array of scoreIDs imported as a result of this import. |
|
|
| `errors` | Array<{ type, message }> | An array of the failed ImportProcessingInfo's Types and Error Messages.
|
|
| `chartIDs` | Set<string> | A set of the chartIDs modified by this import. This is a set to ensure that every chartID here is unique. |
|
|
| `scorePlaytypeMap` | Record<Playtype, Array<Score>> | All of the score documents returned filtered into Playtype buckets.
|
|
|
|
### What's with ScorePlaytypeMap?
|
|
|
|
Some imports may import scores from multiple Playtypes. We
|
|
frequently want to only refer to the set of scores modified
|
|
under a given playtype (For importing a users game:playtype stats, as an example)
|
|
so this is a very useful data structure to have.
|