mithril.js | A JavaScript Framework for Building Brilliant Applications | Frontend Framework library

You need to use dangerouslySetInnerHTML, however it is not recommended.

It is really hard to write correct code without knowing the implementation or documentation of the base Modal class. To work around the API you have mentioned we can render a div in content with a random id that we use later to find it after it is placed into the DOM tree. Then inject the SVG into that div and use D3 as you normally would. I'm not sure if D3 needs cleanup but that would be done in onremove, again make sure to call the parents onremove if necessary.

I use JSX in content but I wasn't able to test its format.

Mithril.js now recommends that you use closures for stateful components. I would recommend migrating to that style because it is a lot easier to reason about where the state is.

Mithril documentation outlining closure components:

In the above examples, each component is defined as a POJO (Plain Old JavaScript Object), which is used by Mithril internally as the prototype for that component's instances. It's possible to use component state with a POJO (as we'll discuss below), but it's not the cleanest or simplest approach.

Regarding the bug you are having, after some testing I think it has to do with the fact that the this you are using in your methods is not the same as editModeElements. As I understand it, mithril uses the POJO as the protoype for the this used in methods. I think maybe when cutting your code down some parts have been altered that make the error occur slightly different for me when I try to make it run. The crux of the issue though is that this != editModeElements and it makes the code really confusing. Sometimes you might be modifying the prototype and other times you might be modifying the instance.

Some of the issues:

1. When you set oncreate: this.update, the this is not editModeElements but the this of the current scope. So most likely this.update is undefined and oncreate is set to undefined and never called.
2. The this passed to createActionEditorList is not the same object as editModeElements.addAction used in editModeElements.addAction.
3. You have some methods refer to actions.actions but editModeElements is initialized such that actions: editedActions.actions.

It is hard to tell what else is going on without the rest of your code. I tried to use POJOs for state at first because I thought that was necessary but closures are way easier to understand. Maybe you could elaborate if you need that style for some reason because it is very difficult to implement reliably.

Here is what I think you want your component to do rewritten using the closure style, I had to stub a few things to make it work, :

As far as I know there is not a great way to perfectly fit d3 into a mithriljs app without just letting d3 run a subtree of the dom by itself.

I created a simple example based off your code above and this mithril js example from the documentation at: bootstrap-fullcalendar-example

Note that the BarChart component always tells mithril that it is only rendering a div inside of its view therefore after its first draw it will never be redrawn again even though d3 is manipulating the dom below that div. This is critical because you don't want to draw something with d3 and then have mithril draw over it or the opposite.

In order to manipulate the bar chart you will have to use d3.select inside the App using the dom element that was saved off in barChartEl. I created a silly example of this that just pushes the bar chart to the right once and then you can reset it with the other button. I don't know enough about d3 sorry but you get the idea. Also note that barChartEl is the div and not the svg node but I can still select down to the g or you could directly select the svg there.

This code was written to use d3 v5 and mithril 2.0.4.

I usually set a locking var in the component's closure. Then use that to control if the submit event is propagated not. I'm assuming you are not submitting the form with JS.

From just an initial read: layout returns a function whereas workingLayout appears to simply define a function and then exit (returning nothing). That includes a call to m(...) but if a call to m(...) is calling that returned function, you have a loop.

As a general good strategy for debugging, when you have a working example and a non-working example, make small changes to one that make it more like the other and test, then repeat, until the behavior of the one you are changing switches to have the same behavior as the one you're changing it to be more like. Then toggle that change back and forth and test that the behavior changes back and forth with it, to confirm that this particular change makes the difference. That's part of making a minimal reproducible example and will often help you solve the problem directly.

I read mithril'docs again and I found that RouteResolvers perfectly suit my needs. Here is an example:

Since your output is a QuerySnapshot, you need to access your data like so:

Since you are probably only want to update the one instance of your component instead of