You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, if you have a static asset like an image or similar that you want to use in Wasp app, you can put it in ext/ and import it via import statement in your JS code, and that works.
However, there might be some benefits to having a more explicit mechanism for it.
@realamirhe commented when I asked what he thinks about current solution (ext/ + JS import) vs smth like static/:
I think it is good enough
The main reasons people are putting their stuff in the public are for the organization (make assets in a separate folder and apply a custom cache control on them all) and loading the file lazily instead of loading embedded format e.g. base64 for images.
Build system converts the imports and they will be resolved to string at the end.
There is nothing impossible that I can imagine right now.
But need to double-check our build process under the need so we can make sure every file which is imported is going to be served okay.
Conclusion: we should investigate what happens with static resources in the way our Wasp apps are currently built, and if we can improve that by doing something like static/.
The text was updated successfully, but these errors were encountered:
Comment above investigated static resources on frontend / client, but users also might want to have them on backend / server.
For example, they might want to add some images or PDFs or something to the server code and make sure it gets deployed together with the app, so it can be accessed directly from the server code (loaded as a file and similar).
They can do that now locally, just put files somewhere in some file in server/ in wasp project and access them, but when deploying, those get skipped by typescript compiler and don't make it into the final build that gets deployed. So there is no way to get those to production as a part of the Wasp server source code right now.
While there are other ways to host such assets, as S3, even db, we still want to support this in case somebody needs this.
What we could do is have a special directory, something like server/assets/, and whatever they put there, we make sure to copy to the built server code while doing wasp build.
Right now, if you have a static asset like an image or similar that you want to use in Wasp app, you can put it in
ext/
and import it via import statement in your JS code, and that works.However, there might be some benefits to having a more explicit mechanism for it.
@realamirhe commented when I asked what he thinks about current solution (ext/ + JS import) vs smth like static/:
Conclusion: we should investigate what happens with static resources in the way our Wasp apps are currently built, and if we can improve that by doing something like
static/
.The text was updated successfully, but these errors were encountered: