Skip to content
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

Allow putting islands + routes + components in the same folder #1486

Closed
marvinhagemeister opened this issue Jul 19, 2023 · 2 comments · Fixed by #1600
Closed

Allow putting islands + routes + components in the same folder #1486

marvinhagemeister opened this issue Jul 19, 2023 · 2 comments · Fixed by #1600

Comments

@marvinhagemeister
Copy link
Collaborator

marvinhagemeister commented Jul 19, 2023

Currently, the way Fresh works is that it scans for an islands/ and a routes/ folder in which Islands and Routes have to live respectively. This grouping by purpose is fine for smaller projects, but grouping by feature makes a lot more sense. Putting everything related to a certain route in the same folder makes a lot of sense.

Another motivation for this feature is that I notice folks putting everything in one single route file as a workaround to having to put the code outside of routes/.

We have the distinct notion of the islands/ and routes/ folder, because it signals to Fresh what to bundle for the browser and what routes to resolve.

The details on this still need to be worked out.

@marvinhagemeister
Copy link
Collaborator Author

From discord: Astro allows you to opt out of route matching via an _ suffix.

@barelyhuman
Copy link

barelyhuman commented Jul 25, 2023

#1126 (comment)

I understand, the plugin is small enough to be added in directly into the core though so it shouldn't be a problem. Also , considering how far Fresh has moved it'd be hard to reason with users with regards to the change in behaviour so I would also not recommend using the web components implantation right now

Let me know if you need a PR for the specific changes of accessing any files as island.

Based on evaluation the easiest one is using the top level comment of //@island which doesn't take any parameters so it's a simple string search and doesn't need parsing.

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants