* Added footer with blank links to be filled
* Cookie consent to match V1
* Made scrolling work on tool search results
* Made scrolling the same on tool search, tool picker and workbench
* Cleaned up height variables, view height only used at workbench level
<img width="1525" height="1270"
alt="{F3C1B15F-A4BE-4DF0-A5A8-92D2A3B14443}"
src="https://github.com/user-attachments/assets/0c23fe35-9973-45c0-85af-0002c5ff58d2"
/>
<img width="1511" height="1262"
alt="{4DDD51C0-4BC5-4E9F-A4F2-E5F49AF5F5FD}"
src="https://github.com/user-attachments/assets/2596d980-0312-4cd7-ad34-9fd3a8d1869e"
/>
---------
Co-authored-by: Connor Yoh <connor@stirlingpdf.com>
Co-authored-by: James Brunton <jbrunton96@gmail.com>
Better tool flow for reusability
Pinning
Styling of tool flow
consumption of files after tooling
---------
Co-authored-by: Connor Yoh <connor@stirlingpdf.com>
Co-authored-by: James Brunton <jbrunton96@gmail.com>
# Description of Changes
Currently, the `tsconfig.json` file enforces strict type checking, but
nothing in CI checks that the code is actually correctly typed. [Vite
only transpiles TypeScript
code](https://vite.dev/guide/features.html#transpile-only) so doesn't
ensure that the TS code we're running is correct.
This PR adds running of the type checker to CI and fixes the type errors
that have already crept into the codebase.
Note that many of the changes I've made to 'fix the types' are just
using `any` to disable the type checker because the code is under too
much churn to fix anything properly at the moment. I still think
enabling the type checker now is the best course of action though
because otherwise we'll never be able to fix all of them, and it should
at least help us not break things when adding new code.
Co-authored-by: James <james@crosscourtanalytics.com>
Component Extraction & Context Refactor - Summary
🔧 What We Did
- Extracted HomePage's 286-line monolithic component into focused parts
- Created ToolPanel (105 lines) for tool selection UI
- Created Workbench (203 lines) for view management
- Created ToolWorkflowContext (220 lines) for centralized state
- Reduced HomePage to 60 lines of provider setup
- Eliminated all prop drilling - components use contexts directly
🏆 Why This is Good
- Maintainability: Each component has single purpose, easy
debugging/development
- Architecture: Clean separation of concerns, future features easier to
add
- Code Quality: 105% more lines but organized/purposeful vs tangled
spaghetti code
---------
Co-authored-by: Connor Yoh <connor@stirlingpdf.com>
Co-authored-by: James Brunton <jbrunton96@gmail.com>
