-
Notifications
You must be signed in to change notification settings - Fork 251
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
Initialization script customization #184
Conversation
@wcrbrm hello there. Thanks for opening this PR. I can definitely see how there is value in being able to customize the JS init script used to load the WASM app. I'll circle back and give this a more in-depth review after v0.13 is released. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wcrbrm thanks for opening this PR! I apologize for how it has taken me to get around to reviewing this.
High-level, I like the approach. Seems quite flexible. Long-term, I think we should create a plugin which allows for full visibility of the manifest and all other outputs of the system. However, the plugin system is not ready yet, so this is quite good.
I have a few comments below about subtle changes which I think would be good. Let me know what you think.
- Before we merge, we need to add documentation on this feature, and the place to do that is the
site
folder. I would say that this should be added to theassets
page.
Co-authored-by: Anthony Dodd <2380740+thedodd@users.noreply.github.com>
Co-authored-by: Anthony Dodd <2380740+thedodd@users.noreply.github.com>
Co-authored-by: Anthony Dodd <2380740+thedodd@users.noreply.github.com>
Co-authored-by: Anthony Dodd <2380740+thedodd@users.noreply.github.com>
Co-authored-by: Anthony Dodd <2380740+thedodd@users.noreply.github.com>
Co-authored-by: Anthony Dodd <2380740+thedodd@users.noreply.github.com>
Co-authored-by: Anthony Dodd <2380740+thedodd@users.noreply.github.com>
Co-authored-by: Anthony Dodd <2380740+thedodd@users.noreply.github.com>
Thanks for detailed review and putting proper wording in docs! Do you want me to modify |
@wcrbrm no worries. I'll update the site. Thank you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! Merging.
/// Optional pattern of the script to be injected instead of standard [default: None] | ||
/// Should include {base}, {wasm}, {js} | ||
pub pattern_script: Option<String>, | ||
/// Optional pattern of the preload links to be injected instead of standard [default: None] | ||
/// Should include {base}, {wasm}, {js} | ||
pub pattern_preload: Option<String>, | ||
/// Can be read only from config file | ||
/// Optional parameters of replacements inside | ||
/// While {var} is being replaced with the provided value, | ||
/// {@path} is replaced with contents of the provided file. | ||
/// This allows insertion of some big JSON state or even HTML files |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to make a small tweak to this once I merge.
Motivation:
The intention behind this PR is to have full control over the script that initialized application and use
trunk
in more cases.While in current version initialization templates are hardcoded, initialization may differ for other frameworks
and require more flexibility for debugging see Sauron SSR as example.
Changes:
pattern_script
field to theTrunk.toml
for overloading the template of initialization script.pattern_preload
field to theTrunk.toml
for overloading the template of WASM preloading.pattern_params
field to theTrunk.toml
for extendingpattern_script
andpattern_preload
with additional values, even including external files.Trunk.toml
and not from environment/CLI because they are typically multiline.Backward compatibility is kept
Checklist
:)
.