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

sendHtml callback #10

Open
klasjersevi opened this issue Jul 11, 2023 · 6 comments
Open

sendHtml callback #10

klasjersevi opened this issue Jul 11, 2023 · 6 comments

Comments

@klasjersevi
Copy link

It would be great if the was a possibility to provide a callback function that gets called right after the injectLiveReload in sendHtml(). That way it would be possible to modify static files dynamically.

// serverOptions example
{
  onSendHtml: (html) => {
    return html.replace("x", "y")
  }
}

Maybe it would be useful to also get the res and status in the callback function?

@oblador
Copy link
Owner

oblador commented Jul 11, 2023

Sounds like a fairly simple thing to implement, but I'm curious of your use case – why do you need this?

@klasjersevi
Copy link
Author

In this case I want to be able to inject som variables from process.env into static .html files. For example the url of a 3rd-party data server, which may be different for each developer. Of course there are many other ways to achieve that, but they are not optimal.

@oblador
Copy link
Owner

oblador commented Jul 12, 2023

I would suggest to have a serverOptions called indexHtml where you can pass any string you want over a callback. That would work with your use case too right?

@klasjersevi
Copy link
Author

Yes, the naming etc are not important to me. I just want to be able to perform something similar to what the injectLiveReload does, but via options.

@klasjersevi
Copy link
Author

Any update on this? Do you want me to submit a PR?

@klasjersevi
Copy link
Author

I would suggest to have a serverOptions called indexHtml where you can pass any string you want over a callback. That would work with your use case too right?

After thinking some time on this I'm not quite sure I understand exactly what you were after? Do you want it work kind of the same as my suggestion but with another name or do you want a different kind of functionality?

If you want a different kind of functionality, what would be your case or goal? It would also clarify if you could provide a simple code example so I can compare to my suggestion?

To clarify my case:
I need to replace different "{SOME_ENV_VAR}" with an env variable in various places in the html file, mostly in html attributes on web components.

<body>
    ...
    <my-component setting="{SOME_ENV_VAR}"></my-component>
</body>

Side note: I have also been using the proposed PR in my project for a while now and it works great for my case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants