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

Rendering of special file types in /assets #48

Open
ispyhumanfly opened this issue Jan 30, 2020 · 0 comments
Open

Rendering of special file types in /assets #48

ispyhumanfly opened this issue Jan 30, 2020 · 0 comments
Assignees
Labels
Milestone

Comments

@ispyhumanfly
Copy link
Owner

So what does this mean? Well I'll tell you. Avian exposes a few publicly available directories for your application. For many frameworks, these are known as the "public" directory, or the "static" directory. Avian already allows you to select which of these is to be used to host static files. You can even choose which one serves static files at /. This is cool.

But one thing that Avian supports that most frameworks do not, is a natively available /assets directory. Many modern application frameworks organize UI related "assets" in a directory known as "assets". It's very common, and you see it more and more. This is why since in the very early days of Avian we acknowledged that this directory could exist in your app home, and we should make it exposed to the internet.

Great, ok...

But wouldn't it be cool if that assets directory could also break up assets like "less, sass, pug, ejs, and even ts files?" Yes it would.

The "static" and "public" directories would work as they do now, they are express.static directories and so there is no way that I know of to preprocess files behind rendered before being exposed to the client.

That's fine. But with assets, we can make it not a static directory. We can have the directory exist, yes, we can have it serve assets, yes, they can even be static, yes, however, if a file being called from /assets/pug/myexample.pug is requested, Avian would be intelligent enough to render the file into html. Same with the other template engines and css preprocessors we support.

We should do this. I don't know of other frameworks that do. Sure, yes, there is a performance penalty for doing this for those files but, if you want to do it you should be able to.

@ispyhumanfly ispyhumanfly added this to the 1.0.0 milestone Jan 30, 2020
@ispyhumanfly ispyhumanfly self-assigned this Jan 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant