Here we have a boilerplate app generated by the create-inferno-app CLI tool. This is just a normal starter project meant to get you up and running with some generated code and a functioning build system. This is pretty much the same thing you'd get with React's create-react-app CLI.
Here in index.js, not much is going on. We're just importing render from Inferno, our app component from app.js in the same directory, and some basic styling from index.css. We're just using the render function to mount our app component to a div with the ID app, and render it to the screen.
Now, let's switch over to app.js, and we see that we're using an ES6 class component, just like you would React, only it comes from a separate package called Inferno component when using Inferno. That's just because the Inferno team wanted to keep Inferno's core a little bit smaller and more focused.
Another thing to make note of here is this constant call to welcome, which is just a string using ES6 string interpolation to print out a welcome message containing the current version of Inferno. That version is just coming from a named export called version from the Inferno core package.
We can see that this welcome message is being used in two separate places in this file. It's directly being used as the inner text of an H2 header that gets rendered at the top of the page, and it's also being passed to an alert in the body of this arrow function called mounted.
That mounted function is being used in the componentDidMount life cycle method of our app component. This is a really simple and straightforward way to demonstrate using life cycle events, but it's perfectly fine for our use case here.
Let's go ahead and edit some text here in this P tag and save the app so that the hot reloading triggers a rerender. We'll see that componentDidMount is firing, and we're getting a welcome message alert as expected.
Now, let's delete this class component, and just paste in basically the same thing in the form of a stateless functional component. The only real difference here is that now we no longer have that active life cycle method, but we're about to change that.
First, let's come up here to the top and delete this class component import, because we're no longer using it. Then over here in our browser, let's switch from our app to the Inferno docs for a moment.
There's two important things to notice here. In the table we see a list of supported life cycle methods with names very similar to class component life cycle methods, but they're all prefixed with the word on.
Below the table this highlighted text says that functional life cycle events must be explicitly assigned via props. If we look down here where their example functional component is being used, we see that onComponentDidMount is being set within the JSX, just like any other prop would be.
Let's go ahead and switch back to our app to try this out. First, we need to export this mounted function as a named export to make it available where we're actually using this app component.
Then let's switch back over to index.js. Just like we saw in the docs, we simply type onComponentDidMount here as a prop, and assign it our mounted function.
We'll briefly see an error here, because I haven't imported mounted yet. Let's fix that, and then save the file. It looks like the alert message fired, and the life cycle event is working, but let's switch back over to app.js to test it again, just to be sure.
Just like earlier with the class component, we can edit the text in this P tag, and save the file so that hot reloading triggers a rerender on save. As expected, the alert message fired again right after the app component mounted.
This is how all life cycle methods work with functional components in Inferno. It's a really nice feature for people who prefer working with functions over classes. This isn't currently possible in React without using a higher order component library, like Recompose.