Passing non-string data to dependent child components

[artfulrobot]

I often have cases like this:

<my-app>
  <my-thing></my-thing>
</my-app>

Or

<my-app>
   html`this.things.map((thing, idx) => html`<my-thing idx=${idx}></my-thing>`)`
</my-app>

What I want is for the child thing to have access to some nested state object from the parent - otherwise the parent has to do something hideous like JSON.stringify() a potentially large object to put it in an attribute, only for the child to have to parse it etc.

I successfully achieved the first example on one project by giving the parent element a reference to the child element, from the child's onConnect(), then letting the parent call methods on the child directly to provide data objects. I've tried to boil this down here:

class MyApp extends ReactiveElement {

  appData = { a: { b: 'c' } };

  registerThing(thing) {
     this.thing = thing;
  }

  somethingHappened() {
   this.thing?.setData(this.appData.a);
  }

  template() {
    if (this.thing) {
       return html`<my-thing></my-thing>`;
    }
   return html``;
  }
}

class MyThing extends ReactiveElement {
   connectedCallback() {                                                   
     super.connectedCallback();
     this.parentElement.registerThing(this);
   }

   setData(d) {
     this.myData = d;
   }

  template() {
    return html`<pre>${JSON.stringify(this.myData, null, 2)}</pre>`
  }
}

It would be nice if I could simply do something like html<my-thing thingData=${this.appData.a} ></my-thing> .

Is there a better way?

I also tried having the child's connectedCallback call a method on the parent to get its data, but this caused infinite recusion errors. The other error I get is "The value of type [object HTMLElement] is not allowed in observables."

(I hit this because I'm now trying to do a hierarchical/recusive treeview with cami.js but I'm interested in discussing the concept at a simpler level first).

[kennyfrc]

Hi @artfulrobot !

What I do in that case is that I use the dot syntax. What that dot essentially does is set a value to a reactive property. Here's an example:

// Instead of this (which would stringify):
html`<my-thing thingData=${this.appData.a}></my-thing>`

// Do this (note the dot before thingData):
html`<my-thing .thingData=${this.appData.a}></my-thing>`

From an example in a real world app I've been working on:

// Simple parent component
class ChatList extends ReactiveElement {
  messages = [
    { id: 1, text: "Hello", type: "user" },
    { id: 2, text: "Hi there!", type: "ai" }
  ];

  template() {
    return html`
      ${this.messages.map(message => html`
        <chat-message
          .messageData=${message}
        ></chat-message>
      `)}
    `;
  }
}

// Simple child component
class ChatMessage extends ReactiveElement {
  connectedCallback() {
    super.connectedCallback();
    // Declare what properties we expect from parent
    this.warnIfMissingProperties(["messageData"]);
  }

  template() {
    // Access the property directly
    const { text, type } = this.messageData;

    return html`
      <div class="message ${type}">
        ${text}
      </div>
    `;
  }
}

customElements.define("chat-list", ChatList);
customElements.define("chat-message", ChatMessage);

[artfulrobot]

Oh, the magic dot! Yes that works! Thank you!

[kennyfrc]

The docs certainly miss this -- there is an upcoming release soon which will also cover that. The release is currently driven by a production app -- once the release there is done, v0.4.0 will follow soon (with some new conventions based on what I've learned so far from using Cami in that codebase).

[artfulrobot]

Sounds good. I have avoided stores because they sound global - I rarely want global things, but I regularly need app-level storage, whereby any nested component has a means to reference the app-level data. Something like "inject/provide" (I think that's Vue or "context" (I think that's Svelte). I'll look up stores in 0.4 when it comes out to see if they can fulfil that purpose.

[artfulrobot]

What a lot of reactive libs assume is that you're building a SPA and that the framework controls everything. More commonly my use cases are that it's a page created by a CMS with some bits of magic here and there by one or more independent, reactive apps. e.g. a donation form that sits in a page, or may be 2 signup forms each for a different purpose.

So I'm very keen on libs like Cami.js and also Alpine Js (which also works well with web components). Many thanks for your work!

[kennyfrc]

Thanks! That context is really helpful. It's my first time seeing Vue's inject/provide and I can see how it's better than prop drilling.

I have two opposite use cases (i.e. a CMS/Shopify site where we want to sprinkle some magic on) and a heavy SPA, and I'm trying to build cami.js to accommodate both (i.e. start with reactive elements for accordions, menus, tickers, etc) and have stores that do some heavier lifting (i.e. sharing state among sibling elements, server querying, caching, client-side routing, etc.).

There are indeed issues with using global stores: 1) since it's global, you'll need better tooling to track state well (I just save the store state in localStorage, and I track its changes there) and 2) dispatch/reducer is a new paradigm for many, and it can be confusing. The nice things about stores is that it scales well as your javascript dependency gets higher (SPAs) and because state and view is cleanly separated, it's very easy to iterate on different views / web components.

In general:

• If the site is CMS-driven / server-rendered / regular web pages: cami's ReactiveElement is enough (and maybe inject/provide as you mentioned)
• If the site is an SPA: you'll need cami stores (but try to avoid doing an SPA if you can due to the complexity)