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
I'm currently using ExternalFluentPlugin in a Vite project. When inspecting the output of the build process, i noticed that the FTL files are included in their raw state in the JS files. This means they have to be parsed into actual FluentResources when they are loaded by a user. I'm wondering what the overhead of this process is and - if it is not negligible - whether it would be possible to handle the parsing of FTL files by the plugin.
Suggested solution
The resulting FluentResource itself has only one property, body, which consists only of simple objects and strings.
So instead of instructing the browser to parse the raw file
import{FluentResource}from'@fluent/bundle'exportdefaultnewFluentResource(`my-string = My String`)
...it should be possible to serve the resulting resource:
exportdefault{body: [{id: "my-string",value: "My String",attributes: {}}]}
Additional context
As mentioned before, I'm not sure what actual effect this change would have on performance. Also, i don't know if this coudl also work for the SFCFluentPlugin.
Thanks for your interest in the library and opening a feature request.
When I was just starting the library, I have tested fluent.js runtime parser, and it was extremely fast. Parsing overhead was negligible compared to the actual formatting.
So I have decided to keep the raw ftl content and the resulting bundle size smaller.
But this is an idea that crossed my mind. I will make a benchmark comparing runtime parsing performance and the resulting bundle size with and without build-time parsing.
With the latest rewrite of unplugin-fluent-vue it should actually be trivial to add a flag to toggle between these two modes.
Clear and concise description of the problem
I'm currently using
ExternalFluentPlugin
in a Vite project. When inspecting the output of the build process, i noticed that the FTL files are included in their raw state in the JS files. This means they have to be parsed into actualFluentResource
s when they are loaded by a user. I'm wondering what the overhead of this process is and - if it is not negligible - whether it would be possible to handle the parsing of FTL files by the plugin.Suggested solution
The resulting
FluentResource
itself has only one property,body
, which consists only of simple objects and strings.So instead of instructing the browser to parse the raw file
...it should be possible to serve the resulting resource:
Additional context
As mentioned before, I'm not sure what actual effect this change would have on performance. Also, i don't know if this coudl also work for the
SFCFluentPlugin
.Thanks anyway for this useful project!
Validations
The text was updated successfully, but these errors were encountered: