Creating Dynamic React Components With JSON Like Data Structures.

We Use React 16

In this article, we'll take a closer look at constructing React Components Dynamically using a map JSON like datastructure. When reviewing this information, keep in mind that this article will be discussing React 16 and up.

What is React?

React (also known as React.js or ReactJS) is a free and open-source front-end JavaScript library for building user interfaces based on UI components. It is maintained by Meta (formerly Facebook) and a community of individual developers and companies. React can be used as a base in the development of single-page, mobile, or server-rendered applications with frameworks like Next.js.

Quickstart

Here is a list of steps you need to get your environment set up to run React. At a high level, you need to install node and ensure you run a few commands which set up React and its Node runtime. These steps are as follows:

• Node
• npx create-react-app my-app
• cd my-app
• npm start

Component Quick Rundown

A react page is composed of components which communicate with each other through commons references and functions. Unlike other languages such as Angular and EmberJS, React flows in a single direction. A parent component will flow data to its child component. In order to execute a parents function, you must pass the parent function to the child component. This is simply calling a function by reference.

Designing a component layout tends to be a bit more trickier because it requires more upfront analysis of describing separations of concern. Let's keep it simple by breaking it down to the following three questions:

• Break the UI into a component hierarchy.
• Build a static version in React.
• Find the minimal but complete representation of the UI state.
• Identify where state should live.
• Add inverse data flow.

Dynamic Components Concept

One of the principles we want to ensure and maintain as much as possible is the principle of DRY (Don't Repeat Yourself). Generally speaking, our components are much more powerful if they are abstract and generally deal with rendering responsibilities. The logic that is responsible in which way they render or present data can be thought of as a component's configuration. Therefore, if we separate the rendering responsibility from the data itself and abstract its information to a separate concern, we have a reusable component that we can pass data into that would will not only render the component we are defining but also support future iterations or representations of that data used in other or common areas across our applications. In fact, components can be reused, not only across our application but also across other applications if we design them in such a way were components accept data as a configuration object rather than simply calling and responding to API events.

Here's an image to showcase what we mean:

Creating This Page

Right now, you are looking at a representation of this article in action. Each page within this website is composed of components which read in configuration data for each corresponding component.

Note - they are locally referencing configuration files and should not be confused with back-end data as they are generally static and do not change. This helps with network latency and performance. Think of each page as a collection of react components with each having its own corresonding configuration file. Each configuration file describes the page in a dynamic manner.

Therefore, We can combine each page with its corresponding metadata and use configuration data to control the number of paragraphs in an article, the title and descriptions of each article, subheadings and so on.

Using the rendering responsibility, we simply read in a metadata object that describes the page and load the corresponding data structure section we are interested in using. Thus, if we have an article we are writing, we could represent the article as a data-structure and compose it like this:

Describing Dynamic Data

Describing the dynamic data implies that our rendering logic should be as flexible as possible. We really want to be able to configure a component in anyway we can think of and allow. We also want our component to intelligently handle whatever data we through at it. Thus, should design with the expectation that something may not exist or be defined. Since this is a common practice, it isn't that difficult for us to overcome this using standard JSX coding constructs.

Let's take a look at how we can rendering content conditionally whether it is available or not. We obviously want to take special attention to the lists and conditionals in our logic.

HTML Injection Consideration

Yes, you are right. That HTML Parser is potentially dangerous on the wrong page and like everything else, you should consider when the appropriate use case when this would not be applicable, however, for the intent and purposes of a blog article, this is not a worthy situation of concern. There is no database call on this page nor is there any back-end system engaged with this system. Even if that where the case, you would hope there would a level of security which would address these types of issues on the API layer and you would be right about that.

Rendering Dynamic Content

Notice in this screenshot we are making some assumptions about our data structure. Therefore, it is important when designing your components to create a standardized naming convention and model hierarchy that fits the needs of your application so that you can essentially develop a convention over configuration approach with render data. Here is an example of how we could render data for a given article:

Conclusion

You can see a complete embedded scenario of a dynamic component here.

Feel free to experiment with this and figure out an approach when dealing with dynamic data. If we combine these practices and principles, we can create truly dynamic sites which can reuse all the components across multiple entities, organizations and representations across different products, platforms and even mediums.