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

provide component data through render method params (constructor props) #119

Closed
thescientist13 opened this issue Oct 14, 2023 · 0 comments · Fixed by #120
Closed

provide component data through render method params (constructor props) #119

thescientist13 opened this issue Oct 14, 2023 · 0 comments · Fixed by #120
Assignees
Labels
0.9.0 documentation Improvements or additions to documentation feature New feature or request
Milestone

Comments

@thescientist13
Copy link
Member

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 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.

export default class PostPage extends HTMLElement {
  constructor(request) {
    super();
    
    const params = new URLSearchParams(request.url.slice(request.url.indexOf('?')));
    this.postId = params.get('id');
  }

  async connectedCallback() {
    const { postId } = this;
    const post = await fetch(`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.

const request = new Request({ /* ... */ });
const { html } = await renderToString(new URL(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.

@thescientist13 thescientist13 added the feature New feature or request label Oct 14, 2023
@thescientist13 thescientist13 added this to the 1.0 milestone Oct 14, 2023
@thescientist13 thescientist13 self-assigned this Oct 14, 2023
@thescientist13 thescientist13 moved this to 🏗 In progress in [WCC] General Activities Oct 14, 2023
@thescientist13 thescientist13 changed the title provide component data through renderToString params (getData alternative) provide component data through renderToString params (constructor props) Oct 14, 2023
@thescientist13 thescientist13 changed the title provide component data through renderToString params (constructor props) provide component data through render method params (constructor props) Oct 14, 2023
@thescientist13 thescientist13 moved this from 🏗 In progress to 👀 In review in [Greenwood] Phase 9 - Standards and Conventions Oct 14, 2023
@thescientist13 thescientist13 added 0.9.0 documentation Improvements or additions to documentation labels Oct 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.9.0 documentation Improvements or additions to documentation feature New feature or request
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

1 participant