State is getting confused for multiple instances of the same component type #2995

EverettMcKay · 2024-11-16T02:54:11Z

EverettMcKay
Nov 16, 2024

Suppose I have several different components with this basic structure:

<Container>
	<Body />
	<Feedback />
</Container>

where Feedback is displayed over the entire Container when the user is done interacting with the Body. (By using position: absolute and z-index:2)
In almost all cases, this works as expected. For example, the general case might be this:

	<ComponentType1 />
	<ComponentType2 />
	<ComponentType3 />

This works. However, this doesn’t:

	<ComponentType1-1 />
	<ComponentType1-2 />

In other words, if I have two instances of the same component type, things break down. What happens? Feedback for ComponentType1-2 is displayed on top of ComponentType1-1.
Code-wise, Feedback is set as the results of a timer. Something like this:

    state.feedbackTimer = setTimeout(() => {
      state.feedbackShown = true;
      m.redraw();
    }, 2000);

But somehow, the state getting changed is for the wrong component.

Is there any reason why multiple instances of a Mithril component would get their states confused like this? And if so, is there a way to prevent this confusion?

dead-claudia · 2024-11-16T03:10:18Z

dead-claudia
Nov 16, 2024
Maintainer

What's your component code look like? This so far only makes sense if your view state is managed outside of your component (a massive anti-pattern, by the way).

2 replies

EverettMcKay Nov 16, 2024
Author

I'm using this shape:

export const Component = (): IComponent => ({
  tag: "component",
  attrs: () => {},
  state: () => {},
  oncreate: () => { },
  oninit: () => { },
  view: () => ( <div>Hello</div>),
});

dead-claudia Nov 16, 2024
Maintainer

@EverettMcKay Are you using that as m(Component())?

JAForbes · 2024-11-16T05:55:50Z

JAForbes
Nov 16, 2024
Maintainer

Is state a global or module scoped variable? Do you mean vnode.state ?

0 replies

EverettMcKay · 2024-11-19T03:55:59Z

EverettMcKay
Nov 19, 2024
Author

Here is the gist of what I am doing (skipping the styling):

interface IAttrs {
  name: string;
}
interface IFeedbackAttrs {
  show: boolean;
}
interface IState {
  feedbackTimer: number;
  feedbackShown: boolean;
}

const Feedback = (): IComponent => ({
  tag: "feedback",
  attrs: () => {},
  state: () => {},
  view: (v: Vnode<IFeedbackAttrs, any>) => (v.attrs.show ? <div>Thank you!</div> : null),
});

const Component = (): IComponent => ({
  tag: "component",
  oninit: (v: Vnode<IAttrs, IState>) => {
    v.state.feedbackTimer = 0;
    v.state.feedbackShown = false;
  },
  attrs: () => {},
  state: () => {},
  view: (v: Vnode<IAttrs, IState>) => (
    <div>
      <button
        onclick={(ev: Event) => {
          ev.preventDefault();
          v.state.feedbackTimer = setTimeout(() => {
            v.state.feedbackShown = true;
            m.redraw();
          }, 2000);
        }}>{`Hello, ${v.attrs.name} `}</button>
      <Feedback show={v.state.feedbackShown} />
    </div>
  ),
});

const HomePage = (): IComponent => ({
  tag: "home",
  attrs: () => {},
  state: () => {},
  view: () => (
    <>
      <Component name="Bob" />
      <Component name="Alice" />
    </>
  ),
});

m.route(document.body, "/home", {
  "/home": HomePage,
});

The problem is that clicking on the button in Alice displays the thank you in Bob.

3 replies

dead-claudia Nov 19, 2024
Maintainer

That doesn't replicate for me. Is there something else missing?

(All I did was drop the type annotations in that and plumb it through Babel instead of TypeScript, by the way.)

EverettMcKay Nov 20, 2024
Author

My apologies... My goal with the code is to summarize my approach, hoping there was an obvious, known problem regarding component state.

I will work on a code sample that reproduces the problem and repost. (I'm not sure what is missing.)

dead-claudia Nov 21, 2024
Maintainer

@EverettMcKay My usual process is just start with whatever the buggy code is, and then just (without committing anything) remove chunks of code and check if it continues to reproduce. It's a bit slower, but it gets me to a minimal repro 100% of the time. (I've even narrowed down a few very subtle TS bugs this way.)

JAForbes · 2024-11-19T05:02:42Z

JAForbes
Nov 19, 2024
Maintainer

I made the smallest change to your example just to get it to work in a code playground. And I can't reproduce the bug:

link

But also there's a few things in your example that seem odd.

state: () => {}, and attrs: () => {}, what is the intention for those function definitions? You don't need that.
What is the intention behind manually setting a tag attribute, e.g. tag: "component"? Again you don't need that.
Why create a closure, but then use v.state, you can define normal variables in the closure and reference them this

I don't know if that helps, but I think if you adapt your source accordingly your bug will probably disappear.

0 replies

EverettMcKay · 2025-10-08T18:42:39Z

EverettMcKay
Oct 8, 2025
Author

At some point I discovered that if you have an array of mithril components of the same type, Mithril apparently feels free to share state. Assigning a key to these components solves this problem.

Apologies for not closing this earlier.

1 reply

dead-claudia Oct 9, 2025
Maintainer

It's not that. It's that Mithril tracks the state identity by position if you don't add keys.

If you do array.map(thing => m(MyComponent, {thing})), the first component is updated with the first thing, the second with the second thing, and so on. It's simple, but often too simple.

Conversely, if you do array.map(thing => m(MyComponent, {thing, key: thing.id})), it takes each thing, moves the previous component with key thing.id to the offset of the current thing, and updates with that previous component. It's more complicated, but also what you usually need with lists of interactive or animated elements.

Uh oh!

State is getting confused for multiple instances of the same component type #2995

Uh oh!

EverettMcKay Nov 16, 2024

Replies: 5 comments · 6 replies

Uh oh!

dead-claudia Nov 16, 2024 Maintainer

Uh oh!

Uh oh!

EverettMcKay Nov 16, 2024 Author

Uh oh!

dead-claudia Nov 16, 2024 Maintainer

Uh oh!

JAForbes Nov 16, 2024 Maintainer

Uh oh!

EverettMcKay Nov 19, 2024 Author

Uh oh!

dead-claudia Nov 19, 2024 Maintainer

Uh oh!

EverettMcKay Nov 20, 2024 Author

Uh oh!

dead-claudia Nov 21, 2024 Maintainer

Uh oh!

JAForbes Nov 19, 2024 Maintainer

Uh oh!

EverettMcKay Oct 8, 2025 Author

Uh oh!

dead-claudia Oct 9, 2025 Maintainer

EverettMcKay
Nov 16, 2024

Replies: 5 comments 6 replies

dead-claudia
Nov 16, 2024
Maintainer

EverettMcKay Nov 16, 2024
Author

dead-claudia Nov 16, 2024
Maintainer

JAForbes
Nov 16, 2024
Maintainer

EverettMcKay
Nov 19, 2024
Author

dead-claudia Nov 19, 2024
Maintainer

EverettMcKay Nov 20, 2024
Author

dead-claudia Nov 21, 2024
Maintainer

JAForbes
Nov 19, 2024
Maintainer

EverettMcKay
Oct 8, 2025
Author

dead-claudia Oct 9, 2025
Maintainer