Closed gabrielromk closed 9 months ago
Good catch. Indeed, the netzo layout plugin injects a default _app.tsx
so user can no longer use a custom _app.tsx
without running into issues. This is due to how fresh works, and if a solution comes, it should come upstream from fresh. Be reminded that you can always use _layout.tsx
files (one per file level) which will render under the auto-injected _app.tsx
.
Keeping this open for now, so that we can add a note to the docs and avoid confusion for users.
Hola chicos, I contribute a lot to fresh, specifically around plugins. What sort of solution are you looking for here? I don't see an easy way of combing an _app.tsx
file from a plugin (or even from multiple plugins!) with one from the user's code. If you could elaborate on what you're looking for, that would be great.
Hola @deer! Thanks for your interest!
I agree, there might be no natural way of combining plugin-injected and user-defined _app
files, and that's ok. Regarding this, I would prefer the current behavior of max 1 _app
file, whether injected or not, in favor of simplifying the mental model when using fresh. That being said, adding a warning whenever fresh detects the presence of 2 or more _app
files (from plugins and/or from user code) would be great. Same goes for _layout
files, with the difference these are scoped at the route-level, rather than global like _app
.
Ok, it seems like the right solution is to dust off https://github.com/denoland/fresh/pull/1568 and finally get that merged. I'll keep any discussions of implementation details there (or more likely in the new PR that I might open), but I guess this would solve your problem.
Thanks for the pointer! Wasn't aware of https://github.com/denoland/fresh/pull/1568, that covers not only this warning but many more! That's great news. Let's keep the discussion over there 👍🏼
Closing as netzo no longer auto-injects an _app
file via plugin in favor of explicitly having an _app.tsx
in the template. So this issue has been solved.
During the migration of the company handbook to the Netzo framework, I faced challenges with the application layout. Despite having all the necessary files installed, including netzo.ts, .env, etc., none of the functionalities were working as expected. After thorough investigation, I identified the problem to be associated with conflicting middleware in the _app.ts file. This middleware was overriding all Netzo configurations. Upon removing the conflicting middleware, Netzo became operational, resolving the issues encountered during the migration process.
with
_app.ts
without
_app.tsx