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
As part of ProjectEvergreen/greenwood#1157, an alternative to getData was identified that could be more useful at the framework level as getData is more of a component / entry point level mechanic, but frameworks will likely have / want to implement their own data loading mechanics, so being able to DI data from the framework would be nice. For example, Greenwood would like to be able to pass in an instance of a Request object, and possibly additional framework metadata.
On top of that frameworks, may want to define their own naming convention for data loading, the most common one being the loader pattern, e.g.
exportdefaultclassPostPageextendsHTMLElement{constructor(request){super();constparams=newURLSearchParams(request.url.slice(request.url.indexOf('?')));this.postId=params.get('id');}asyncconnectedCallback(){const{ postId }=this;constpost=awaitfetch(`https://jsonplaceholder.typicode.com/posts/${postId}`).then(resp=>resp.json());const{ id, title, body }=post;this.innerHTML=` <h1>Fetched Post ID: ${id}</h1> <h2>${title}</h2> <p>${body}</p> `;}}
Details
In theory a framework could import / call getData itself as a generic loader pattern, WCC would still run it itself too as part of rendering, incurring a double fetch. Also this makes the name flexible, and could let frameworks take on more complex requirements like ProjectEvergreen/greenwood#880.
So instead of relying only on WCC to do the data fetching and orchestration, we could pass these "constructor props" to WCC and it can inject that data into the top level component of the entry point, e.g.
constrequest=newRequest({/* ... */});const{ html }=awaitrenderToString(newURL(moduleUrl),false,request);
This may beg the question if WCC should even have a data loading mechanic, so it might be good to spin up an issue or discussion for that.
The text was updated successfully, but these errors were encountered:
thescientist13
changed the title
provide component data through renderToString params (getData alternative)
provide component data through renderToString params (constructor props)
Oct 14, 2023
thescientist13
changed the title
provide component data through renderToString params (constructor props)
provide component data through render method params (constructor props)
Oct 14, 2023
Type of Change
Feature
Summary
As part of ProjectEvergreen/greenwood#1157, an alternative to
getData
was identified that could be more useful at the framework level asgetData
is more of a component / entry point level mechanic, but frameworks will likely have / want to implement their own data loading mechanics, so being able to DI data from the framework would be nice. For example, Greenwood would like to be able to pass in an instance of aRequest
object, and possibly additional framework metadata.On top of that frameworks, may want to define their own naming convention for data loading, the most common one being the
loader
pattern, e.g.Details
In theory a framework could import / call
getData
itself as a genericloader
pattern, WCC would still run it itself too as part of rendering, incurring a double fetch. Also this makes the name flexible, and could let frameworks take on more complex requirements like ProjectEvergreen/greenwood#880.So instead of relying only on WCC to do the data fetching and orchestration, we could pass these "constructor props" to WCC and it can inject that data into the top level component of the entry point, e.g.
This may beg the question if WCC should even have a data loading mechanic, so it might be good to spin up an issue or discussion for that.
The text was updated successfully, but these errors were encountered: