This repository was archived by the owner on Apr 8, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 8, 2020. It is now read-only.
Proposal: Add ability to pass @Model to prerendered boot func #107
Description
It would be nice to see some ability to pass extension model for our prerendered components. It could be very helpfull for some redux/flux apps (we could populate initial state with them). And it could reduce total overhead of loading some info via Http requests.
Proposal api looks pretty simple. In tag helper add populate new attribute:
<app asp-prerender-module="ClientApp/boot-server"
asp-prerender-model="Model"
asp-prerender-webpack-config="webpack.config.js">Loading...</app>
Inside boot func there is new optional parameter, which popuated from asp-prerender-model attribute:
export interface BootFunc {
(params: BootFuncParams, model: any): Promise<RenderToStringResult>;
}
Such feature would be really good for building some dynamic parts for exist applications (not whole application handled by some JS-framework).
Activity
feat(prerender): ability to push payload and model to boot func
SteveSandersonMS commentedon Jun 14, 2016
We might want to name it something more general than "model", as you could use this to pass arbitrary information, which could include things like authentication status, which component to render, etc. as well as initial data.
Maybe
asp-prerender-dataorasp-prerender-paramswould be a better attribute name.laskoviymishka commentedon Jun 14, 2016
@SteveSandersonMS MVC usually operate with
Model' verb for passing some information to view. This not realparamsordata` IMHO.SteveSandersonMS commentedon Jun 14, 2016
Are you saying that you agree that "params" or "data" are better terms than "model" because they are more general? If you mean something else please clarify.
Of course, "params" or "data" could include some set of "model" values as subproperties, if that's the information you want to pass to the boot function.
laskoviymishka commentedon Jun 14, 2016
No, I stand for separation of concerns. This should stay as model, or maybe data.
SteveSandersonMS commentedon Jun 14, 2016
Having the ability to pass an arbitrary set of properties into the boot function will cover all the requirements we've discussed here. It's up to the developer to assign whatever meaning they want to those properties, and as such they can separate their concerns in any way they want.
laskoviymishka commentedon Jun 14, 2016
Yeah, but it force developer to use low level http context stuff in view layer.
laskoviymishka commentedon Jun 14, 2016
May be it better to give developer an option.
If they don't wanna use any hooks - okay, use an data or model passing direct to you prerendering.
If they want to introduce some generic behaivior - okay, use hooks, and populate this context data for every prerender.
Why we should reduce API? Hooks applicable in many scenarios. Especially for enterprise solutions, with all this layers and abstractions.
Separating this concerns into 2 different API is not break anything, it still could be possible to pass everything in a
Model, or viaHook. This just a good option. Let developer decide what he or she want to use.SteveSandersonMS commentedon Jun 21, 2016
I've implemented and documented
asp-prerender-data, and it's now published. To get this feature, make sure you're onSpaServices1.0.0-beta-000005 or later, and that youraspnet-prerenderingNPM package is on version 1.0.2 or later. There's a usage example in the docs - see the "Passing data from .NET code into JavaScript code" subheading.Minimising API surface is essential for the long-term health of this - or any other - framework project. Every public API needs ongoing support, and you can never predict in advance what future enhancements would be precluded by decisions made now. As is often said in open source "No is temporary; yes is forever".
In this particular case, if you do want this global pipeline-hooks type design, you can certainly enable that using
asp-prerender-data. Just create your own tag helper that wrapsasp-prerender-*, gets the global context information from wherever you want, and pass it to theasp-prerender-*tag helper asasp-prerender-data.Longer term, if we hear requests from many other developers for a built-in implementation of that, we can certainly consider adding one. I just would not want to bake those design decisions into the packages so early on without evidence that a substantial number of developers will want it. We are yet to see how people will use
asp-prerender-dataand what patterns will emerge around it. Hope that's OK!colltoaction commentedon Aug 9, 2016
What is
asp-prerender-exportfor?jeinz11 commentedon May 28, 2017
Hi i think its a good idea to pass the cookie in the server side rendering, right now my api is secure
so the first request is unauthorized and server side rendering is totally useless for me thanks