-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/change app structure #1063
Conversation
Camel-casing is used on the other types so changed this to keep it consistent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work restructuring the load functions and fixing the types (and gathering all types in the $lib
folder)! ⭐
It would be preferable to merge this soon to minimize the need to resolve merge conflicts (we’re currently working on relatively few simultaneous changes in the code base so it would fit very good timewise).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 🚢
Description
Solves
Made an attempt at re-structuring the app (or really, reverting it to how it once was), mainly since
(find)/+layout.server.ts
has grown a bit out of hand and the search result really feels like it should be a component rather than a layout template. Also tried to gather the types and utils that were placed all over.With this approach, we can begin to optimize the data fetching for the resource page, without worrying about breaking things on the /find route for example. The types that got lost in the resource load function are now back etc etc.
(On the downside, the load functions now have some duplicate logic. If this feels like a problem, we could maybe delegate it to an internal /find api route?)
Before:
After:
Summary of changes
<SearchResult>
component