DEV Community: Sebastijan Grabar

Configuring Gradle and Spring Boot with H2 for local development

Sebastijan Grabar — Thu, 18 Nov 2021 14:35:02 +0000

If you're anything like me, you HATE long compilation times. Frequently, we find ourselves in an absurd situation where we discover a new programming language that we love so much, but it also has slower compilation times when compared to its predecessor. Prime examples are Kotlin and TypeScript. It also seems that compilation times are just getting slower, version by version. It's a sad, sad world.

As the famous XKCD comic jokes:

If you're also like me, you absolutely LOVE good tooling. Good tooling has the potential to make our lives easier, enable us to lose less time waiting or doing empty work. HotSwap for JVM or TypeScript Language Server comes to mind.

The problem with Spring Boot and databases

There's no such thing as a free lunch. Sure, Spring Boot has awesome tooling, great development experience. But, it is famous for its NOTORIOUSLY bad start-up time. Some Spring Boot apps take longer to start than my entire OS. It's just hilarious.

Oftentimes, a major contributor to the start-up time is initializing the connection to the database. If you're using Flyway or Liquibase, it is even worse, as it takes time for them to validate your database, or change it if needed.

To waste some more of your precious time, people usually configure their local development environment to use an external database, so you also need to start this as well. Sure, it's good to use the same database for your local development as you do in production, but it's so unnecessary. Configure your integration tests to use that database to check for any potential errors.

Need to modify your database schema? Good luck restarting your DB instance each and every time you make a change.

Using H2 in-memory DB for local development with Gradle

The solution to the mentioned problem is to just use an in-memory database for local development. It's going to make your life so much easier.

Let's see how we can configure Gradle to use H2, but only for local development.

As an example, let's say that we have an application with dependencies that look like this, in your build.gradle, with PostgreSQL as your production database:



dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    runtimeOnly 'org.postgresql:postgresql'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

You can just add the H2 dependency to this section, but that would mean that in production, your app is going to have the H2 included in it as well. Let's not do that. It's filthy.

By default, the java plugin in build.gradle declares two source sets, main and test.

What we're going to do is add a new sourceSet and configuration just for local development in build.gradle. We can call it localH2. You will need to add this piece of code before declaring your dependencies.



configurations {
    localH2Implementation.extendsFrom implementation
    localH2RuntimeOnly.extendsFrom runtimeOnly
}

sourceSets {
    localH2 {
        compileClasspath += sourceSets.main.output
        runtimeClasspath += sourceSets.main.output
    }
}

This configuration enables us to define dependencies that are specific only to our local environment. But, it includes the whole main source set, so you'll have all the dependencies that you included normally.

We can now add the H2 dependency, like this:



dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    runtimeOnly 'org.postgresql:postgresql'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'

    localH2RuntimeOnly 'com.h2database:h2'
}

We're almost there, but now, in our localH2 source set, we also have the PostgreSQL driver included. To remove that dependency, we can use this block of code:



configurations.localH2Implementation {
    exclude group: 'org.postgresql', module: 'postgresql'
}

Ah, now everything is so clean.

Running a Spring Boot application with the local configuration

We now have two classpaths separated, for the production code and for our local development. But, we haven't explored how we can run this local configuration from your machine. If you just run the application through your IDE or with ./gradlew bootRun, it's just going to use the production classpath.

If you're using IntelliJ, you'll have to make a small change in your Run Configuration to use the new classpath.

If you're running your app with ./gradlew bootRun, don't worry, it's a pretty simple change as well.

You can add a new Gradle task to your build.gradle to run it with the new classpath, like so:



task localH2(type: org.springframework.boot.gradle.tasks.run.BootRun){
    mainClass = "gradle.springboot.h2.local.example.ExampleApplication"
    classpath = sourceSets.localH2.runtimeClasspath
}

The mainClass property should contain a reference to your main Java class. You can now run your app by calling ./gradlew localH2. Isn't it nice?

Even better, having H2 in the classpath configures your DataSource automatically, so there's no additional configuration to be added.

Important note

If you had your DataSource configured in your application.yml / application.properties, you should pull that config out into a new profile (let's say, postgres?), so that it's not loaded by default.

Final thoughts

Get ready to indulge in the newfound time that you didn't even know you had. Too many times, have we, as developers, had to wait for that slow Spring Boot app to start.

There are at least some ways to make our lives easier and isn't that the whole point of DevOps and the rapid development culture of today?

Be safe!

The accompanying code can be found at the Github Repository.

Dead simple REST API validation with Spring Boot (seriously, very simple)

Sebastijan Grabar — Tue, 05 May 2020 16:57:39 +0000

This post is written in a pretty leisurely fashion

REST API validation... I seriously think that people don't really like to do it, or they just do it sloppily. In other words, people don't care about validation as much as they should. The end result is not really that catastrophic, at least in the Spring Framework ecosystem. Usually, some method deeper in the call stack will throw an Exception and Spring will take care about the rest of it. You will probably get a HTTP 4xx or 5xx status code as the response, with some (usually) undecipherable call stack. Who reads call stacks from HTTP responses anyway, we're not crazy. Someone might say it's not such a big deal, since there's a good chance that no harm has been done and end users won't notice it. Well, except if you show them all the HTTTP error messages, in which case, your mistake.

Oh hell. No.

Seriously, do your validation. Do it right. You'll be happier.

Spring can have some pretty scary and complicated validation logic when you first look at it. It doesn't have to be though.

In this post, I'll show you one way. The way I love to do it. We'll validate us some query parameters.

Meet Lombok

Chances are, if you're programming with Java, you are already using Lombok. Mighty fine. Lombok is insanely awesome and I am really glad that I have a chance to be using it.

If you don't know what Lombok does for you, here are some basic things that it can do:

generate all the getters and setters for your class fields
generate constructors with all/no parameters
generate a Builder for your class
generate hashCode() and toString() methods for your class
do all sort of data mapping with delegates

For purposes of this post, we'll only be using the @Data annotation, which will generate no args constructor and all the getters and setters.

Preparing your project

We're not going to delve into Spring basics here, what's Maven/Gradle and other unnecessary stuff. The only thing you need to do, if you want to follow this tutorial, is:

Go to https://start.spring.io/
Add Spring Web and Lombok as dependencies
Select Java as the Language (if you haven't realised this post is about Java yet)

Validating query parameters in Spring controller

Okay, let's say that as an example, I want to make an endpoint that will fetch us some entities. What type of entities, we don't care at all at the moment, the only thing we want to do right now, is validate the parameters that are coming into the controller method.

If you're a little confused, the parameters I'm talking about are query strings, or query params, whatever you want to call them. Basically, they are a way to parameterize a URL.

Let's say we want 4 parameters coming into our controller method that we want to validate, with the following rules:

name - must be provided
timestamp - must also be provided and must be in correct format (ISO 8601)
code1 - must be exactly 3 alphanumerical characters
code2 - must be between 4 and 5 characters long

Yes, I know. I'm very imaginative with my naming. Bear with me.

An additional rule we want to have is that we have to provide either code1 or code2, or both of them. That's some more complicated logic right there.

So another rule:

code1 or code2, or both, must be provided

Now I'm just going to show you the whole code for it.

package com.example.demo;

import lombok.Data;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RestController;

import javax.validation.Valid;
import javax.validation.constraints.*;
import java.time.Instant;

@RestController
public class DemoController {

    @GetMapping("query")
    public void queryParams(@Valid RequestParams params) {
        // your controller code here
    }

    @Data
    public static class RequestParams {

        @NotBlank
        private String name;

        @NotNull
        private Instant timestamp;

        @Pattern(regexp = "^[0-9A-Za-z]{3}$")
        private String code1;

        @Size(min = 4, max = 5)
        private String code2;

        @AssertTrue(message = "You must provide at least code1 or code2")
        private boolean isCode1orCode2Provided() {
            return code1 != null || code2 != null;
        }
    }
}

Let me explain, through steps:

Create a new class that has all of your parameters. Note that it doesn't need to be named RequestParams, I just named it like that for this example. Spring will bind all the query params to your class - by default.
Use Java Bean Validation API (JSR-380 specification, that's from javax.validation package) to put any constraint you want on the individual query params.
Use @AssertTrue to handle any of the validation requirements that handle multiple query params. The method annotated with this annotation must return true for the whole request to be valid.
Accept the new class in your controller method and put on a @Valid annotation. The annotation enables validation for this object, which is done by Spring. Spring will bind all the query params to your class - by default.
Profit!

I'm not going to go through what each of the annotations does, you can find that out in the official spec (https://beanvalidation.org/2.0/spec/#builtinconstraints) or the matching JavaDoc (https://javaee.github.io/javaee-spec/javadocs/javax/validation/constraints/package-summary.html). I hate JavaDoc, so I just do it through the IDE.

There's no more implementing custom validators, ugly controller method signatures, custom validation annotations and all the things that in the end just make you project more bloated. YAGNI!

Seriously, there are so many different annotations to choose from in the javax.validation package, that there's a good change they might just be all you need. Usually, you can validate almost every field with only these annotations and for everything else, you can use @AssertTrue. There's also an @AssertFalse annotation, if it suits you more to write the validation in the other way. You can also add a custom message for any of the annotation, if the default ones aren't enough (they usually are, though). Check it out yourself, experiment!

Let's test this now. We'll try to make a request that violates one of our validation rules, let's say, we don't send code1 and code2 and expect that we get an error message.

If we run the application and make a GET request with this URL:
http://localhost:8080/query?name=johnny&timestamp=2018-08-29T09:25:01Z

we'll get a HTTP 400 status code and the following response:

{
    "timestamp": "2020-05-05T16:21:09.450+0000",
    "status": 400,
    "error": "Bad Request",
    "errors": [
        {
            "codes": [
                "AssertTrue.requestParams.code1orCode2Provided",
                "AssertTrue.code1orCode2Provided",
                "AssertTrue"
            ],
            "arguments": [
                {
                    "codes": [
                        "requestParams.code1orCode2Provided",
                        "code1orCode2Provided"
                    ],
                    "arguments": null,
                    "defaultMessage": "code1orCode2Provided",
                    "code": "code1orCode2Provided"
                }
            ],
            "defaultMessage": "You must provide at least code1 or code2",
            "objectName": "requestParams",
            "field": "code1orCode2Provided",
            "rejectedValue": false,
            "bindingFailure": false,
            "code": "AssertTrue"
        }
    ],
    "message": "Validation failed for object='requestParams'. Error count: 1",
    "path": "/query"
}

You might say that the response is too huge for just a validation error message, but why should that be a problem? More often than not, error messages are for developers, not the users. I'd rather have a bigger error message, than a smaller one. And from this one, you can find out a LOT.

The other way

The other way to do validation of query params is through the inline @RequestParam annotation. Like in the example below:

package com.example.demo;

import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.server.ResponseStatusException;

import javax.validation.constraints.NotBlank;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Pattern;
import javax.validation.constraints.Size;
import java.time.Instant;

@RestController
public class DemoController {

    @GetMapping("query")
    public void queryParams(
            @RequestParam @NotBlank String name,
            @RequestParam @NotNull Instant timestamp,
            @RequestParam @Pattern(regexp = "^[0-9A-Za-z]{3}$") String code1,
            @RequestParam @Size(min = 4, max = 5) String code2
            ) {

        if (code1 == null && code2 == null) {
            throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "You must provide at least code1 or code2");
        }

        // your controller code here
    }
}

Our method signature now looks kinda.... big. There's a lot going on, for sure.

I deliberately put some validation logic inside the controller code. Is that wrong? I don't know, maybe not, but it sure does leak validation logic into the place (I'm talking about the method's body) where other things should be happening. And now you also have two kinds of messages to expect from your REST API when there's a validation error. If you think about it, the interpreter should never reach the method body, if the query params aren't valid.

The "correct" way would be to implement a custom validation annotation and it's corresponding handler (a class that in some way implements the Validator interface).

If you do that, you already added two extra files. To validate one simple thing. The syntax to do that is also kind of, well, sad. Or, maybe, you just want your codebase to look more Enterprise. No thanks, I'll avoid that with a very big radius.

Notice that I put correct in quotes. I don't really think that there is an absolutely correct way. There are better ways and worse ways, more maintainable ways and less maintainable ways, prettier ways and uglier ways. It all depends on what you want.

Other uses, eg. validating the request body

Example from this post focused on validating query params. You can basically use the same API to validate the request body as well. The only thing you need to add is the @RequestBody annotation along with @Valid, so that Spring knows that it has to bind the request body to this object and not the query params.

Everything else remains the same.

That way, you can easily validate your incoming DTOs and you don't need to worry about complex validation logic. And, it's so easy to add new DTOs.

Conclusion

If you like doing things concisely and with less code, this way of validation will leave you satisfied. Spring Framework and the JSR-380 API works wonders. This way, you'll have a standardized validation logic across your whole application and standardized set of responses for the validation errors as well. And you have to do almost none of that yourself.

Granted, this approach has some downsides. For example, unit testing the validation logic is one problem. Should you test features of Spring Framework? Probably not! But, you might want to test the custom logic that you have in the methods annotated with @AssertTrue and @AssertFalse. There are ways around that, because you can externalize these methods with method references, but this whole "less code" story then falls into the water.

That argument stands only for unit testing. You can however, integration test your controller (so that the whole Spring behemoth starts) and only test it for the validation. Can that count as unit testing? Might as well, if you ask me.

Other downsides, I don't know. You tell me.

The (Redux) Saga Continues — Implementing your own redux-saga like middleware

Sebastijan Grabar — Mon, 03 Jun 2019 11:47:54 +0000

So, you have written your first React application with Redux. You used redux-thunk, redux-promise or redux-saga as your middleware, enabling you to perform API calls with simple Redux actions. Life is great, but then you start to wonder, what exactly is that middleware doing with my actions? What kind of magic is going on when I write those thunks?

In this article, we will try to explain what happens there and how you can implement your own middleware for Redux, based on a popular option, redux-saga, which I highly recommend you check out.

A little background

If you aren’t familiar with Redux already, I will try to provide a **very **simplified explanation, without any actual syntax.

Redux is an application state container, which stores state in a single object called the store.

The store can get occupied only by the data that is returned by special functions called the reducers.

Reducers are pure functions, which means they always return the same result for a given input. That is the reason why Redux is called a predictable state container, you can always know what will be in the store based on the input received by the reducers. Those inputs received by the reducers are called actions. Actions always have a type and optionally carry additional data, based on which the reducers put data in the store. Then there’s the **middleware, **which sits just between the actions and the reducers. It is a mediator which can read the dispatched data (a fancy name for calling an action) and then do something with it. Usually, middleware is used for logging, sending error reports or fetching data asynchronously and then passing the action along to the reducer with the acquired data.

The workflow looks something like this.

If you used Redux before, chances are you’ve already used some middleware. Usually, you would use middleware that enables you to dispatch actions conditionally (or not to dispatch them), based on the result of some side-effect (an API call for example). But, middleware can actually be used for absolutely anything that you want to do with your data before it reaches the reducer, say logging, or sending an error report to the administrator if the application has crashed.

Creating the store

To keep this fairly short, I will use create-react-app to generate our application, with React already setup, and then install redux and react-redux to connect the two easily. We won’t be doing much with React here, so don’t worry if you aren’t familiar.

The goal in our simple demonstration app will be to fetch data from some web API, save it to Redux with the use of our middleware and display it to the user.

Firstly, we will write a simple reducer, which will save the data received from the API. The API I will be using returns random person info, with the name, surname and country. This is the data which we want to save to the store. We will have three action types our reducer will handle: FETCH_DATA_REQUEST, FETCH_DATA_SUCCESS and FETCH_DATA_FAILED.

Our reducer would look something like this. We will put this bit of code in a new file called reducer.js.

Next, we want to create our store instance and put in a file called store.js. To create a Redux store we use the function createStore exported by the Redux package, which receives the root reducer with all the reducers combined through combineReducers and a store enhancer argument. We will use a built-in enhancer applyMiddleware, which will receive our middleware once we write it.

Our store.js would look like this.

Creating the middleware — implementing the base

Now, looking at the Redux docs (https://redux.js.org/advanced/middleware), we can see that middleware is a curried function that receives three arguments. If you don’t know what currying is, it’s basically returning a function from a function, each receiving a single parameter. The parameters are store, next (which is basically a dispatch function) and action.

If you take a peak at Redux docs, you can write your first middleware in seconds.

Congratulations, you have just written a logging middleware! This will log every action type to the console. But we don’t want to write a logging middleware right now, we want to make async calls with our middleware.

As I mentioned before, our middleware will be based on redux-saga. The basic principle in redux-saga is this, you set some watchers to watch for specific action types and execute a function which will handle that action, called the handler. So let’s start from there.

Since we want to save which actions we will be watching for, our middleware runner will have an actual instance, which will then determine if the middleware is executed or not.

We can write a simple class for that and put it in a new file called middleware.js. It will register action types that need to be processed and their handler function. The class can be called MySaga and looks something like this.

The method registerAction will save action type and handler function pairs to a Map, which provides us with a convenient way to access the handler function later on.

Creating the middleware — implementing the middleware runner

Now comes the tricky part.

Redux-saga is implemented with the use of generator functions. Generator functions unlike regular functions pause their execution when they encounter the yield keyword. Their instances also work like an iterator — you can call .next() method on them, which will return two things — an object with the value of the expression after the yield keyword, and a done property. When .next() is called, the generator function will resume its execution until it hits the next yield.

You can find out more about generator functions on MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*).

Finally, now comes the actual middleware part. The very middleware will be a method that can be called on a MySaga instance.

First, we want to check if the action that is currently in the middleware has a handler function.

We call next(action) at the end of the middleware so it can be processed by the next middleware in the chain (if it exists) and in the end, reach the reducer.

If the handler function (which is a generator) exists, we can call an instance of it and assign it to a variable and yield our first value. The goal is to somehow reach the end of the generator function by calling .next() until the done property is true.

I will now just paste the code below and explain what happens below.

First, we assign a generator function instance to a variable called handlerInstance and pass an action to it received by the middleware. At this moment, our handler function has already stopped at the first yield.

We want to call the .next() method on the instance to find out if we have yielded a value or if the generator is finished executing (the done property is in that case set to true). Next, we enter the while loop which loops until we have reached the end of the generator function. By this time, you can see that the while loop is iterating the generator. In our generators we don’t actually do any asynchronous work, we only provide the middleware with the so called effects, which are plain Javascript objects that instruct the middleware what to do. That inherently makes this middleware pretty easy to test too, you can just call these generator function by yourself (not in the middleware) and observe if they yielded the correct effects.

For our demo implementation we will just have two effects: put and call.

Call will have an asynchronous function that returns a Promise and an arbitrary number of arguments with which we want it to be called.

Put will have an action that you want to dispatch, it’s basically instructs the middleware call the dispatch function with the desired action.

We want to have some factory functions that yield those effects to the middleware. We can save them to a new file called effects.js.

You can now really see what happens in that while loop in the middleware. If the effect yielded is a “CALL“, we want to call that async function and wait for the result with the await keyword. As you can see, the while loop is wrapped in an IIFE (Immediately-invoked function expression), which allows us to use async/await in this block of code. When the Promise is resolved we can assign yieldedValue the next yield value and break out of the switch case. As you can see, we are calling .next() method with the response data as its argument — that will evaluate the yield expression (with the yield keyword) in the generator function as this argument, making it possible to assign the data received from the Promise to a variable. If our Promise didn’t resolve, we can just throw an Error to our generator function with the .throw() method. If you aren’t familiar with .apply() method, it simply provides us a way to call a function with the arguments passed in as an array (in our case the array is the args property on the “CALL” efffect).

If the yielded effect is “PUT“ we just call the dispatch function and call the .next() method. The default case also calls the .next() method, so any yields that don’t return effects are ignored.

And that is about it, our middleware is complete. Now the only thing that’s left to do is to use it.

Using the middleware

To make use of our middleware we first have to make an instance of it and registering which actions we will be handling. We can do that in store.js so it looks something like this.

The fetchDataWorker is our handler generator function that we can write in a new file called sagas.js. Generator functions can be identified by the asterisk at the end of the function keyword.

Our file could look something like this.

I used axios to make a call to an API that returns random names and I put a little gender modifier just to test if our “CALL“ effect works properly when we pass it an argument. We wrapped the API call in a try/catch block for convenience. Remember, we throw the error to the generator function in the middleware, so that it can be caught here. So, in a nutshell, we first make an API call and when it is finished we store it into the response variable. This is possible because we called .next() with the response argument and only then can the generator function continue with the execution. After that, we simply dispatch a success action to be saved to the store. If the error occurs, we dispatch a “FETCH_DATA_FAILED” action.

Testing it in a React application

Now, we can finally test what we have written. We will delete everything that App.js returns in our src folder and create two buttons that fetch us a random female and male person. We also create a simple action creator to dispatch the “FETCH_DATA_REQUEST“ action. The App.js file looks something like this.

Add a little bit of CSS and voilà.

That’s our working async middleware in action! Of course, this is by no means a production ready solution, but it shows the basic principles for building a redux-saga like middleware.

Big respect to the folks that developed it.

The Saga continues

Congratulations for staying with me this far! I sincerely hope you learned something from this article and if not, I just hope that you had fun along the journey. It sure was a journey for me as well!

Now, the real adventure can begin. Have fun!

Originally posted on Medium

Recursive rendering in React: Building a universal JSON renderer

Sebastijan Grabar — Sun, 14 Oct 2018 14:15:06 +0000

In the last year, I have been working with React extensively, both for work and for my own satisfaction. I stumbled upon some pretty interesting patterns, but never did I see recursion being used in rendering React components. If you have any kind of computer science education, you were probably taught what recursion is pretty early on. What recursion does, essentially, is calling the exact same function it is currently in, until the argument is some base case which we define.

Recently, I had a task to create a React component which will render some JSON that is obtained through an API. If you are a web developer, you are probably aware that you can never be 100% sure what an API will return, and if you don't think that is the case, I recommend that you think about it, maybe you will change your mind. The web just isn't statically typed. There is one thing we will assume in this article, the API will always return some kind of JSON (or nothing).

The JSON I needed to render was an ugly, nested one, with multiple hierarchy levels. You could never know if those levels will be populated or not, will they be an empty array or null, etc. The naive way would be to create a component for every hierarchy level, and after a few minutes of being in a mindset of "oh, not again", I had an idea to recursively render those levels, exciting! As a computer programmer, I absolutely love recursion and fun ways to solve these kinds of problems.

Creating the component

The dummy JSON which we will be testing is generated with JSON Generator. As you can see, it has null values, empty arrays, empty objects, arrays with null values and objects with null values. Our max depth is 4 levels.

const testJson = {
  "_id": "5bc32f3f5fbd8ad01f8265fd",
  "index": 0,
  "guid": "87cfbb5d-71fb-45a7-b268-1df181da901c",
  "isActive": true,
  "balance": "$3,583.12",
  "picture": "http://placehold.it/32x32",
  "age": 31,
  "eyeColor": "brown",
  "nullTestValue": null,
  "arrayWithNulls": [null, null, null],
  "objectWithNulls": {
     "firstNullValue": null,
     "secondNullValue": null     
  },
  "name": "Becky Vega",
  "gender": "female",
  "company": "ZOID",
  "email": "beckyvega@zoid.com",
  "phone": "+1 (957) 480-3973",
  "address": "426 Hamilton Avenue, Holtville, New Hampshire, 3431",
  "about": "Duis do occaecat commodo velit exercitation aliquip mollit ad reprehenderit non cupidatat dolore ea nulla. Adipisicing ea voluptate qui sunt non culpa labore reprehenderit qui non. Eiusmod ad do in quis cillum sint pariatur. Non laboris ullamco ea voluptate et anim qui quis id exercitation mollit ullamco dolor incididunt. Ad consequat anim velit culpa. Culpa Lorem eiusmod cupidatat dolore aute quis sint ipsum. Proident voluptate occaecat nostrud officia.\r\n",
  "registered": "2016-11-19T01:14:28 -01:00",
  "latitude": -80.66618,
  "longitude": 65.090852,
  "tags": [
    "ea",
    "officia",
    "fugiat",
    "anim",
    "consequat",
    "incididunt",
    "est"
  ],
  "friends": [
    {
      "id": 0,
      "name": "Genevieve Cooke",
      "ownFriends": {
         "1": "Rebbeca",
         "2": "Julia",
         "3": "Chopper only"
      },
    },
    {
      "id": 1,
      "name": "Eaton Buck"
    },
    {
      "id": 2,
      "name": "Darla Cash"
    }
  ],
  "greeting": "Hello, Becky Vega! You have 8 unread messages.",
  "favoriteFruit": "strawberry"
}

We will start by creating a new React project with TypeScript (because who doesn't like static typing?).

yarn create react-app recursive-component --scripts-version=react-scripts-ts

Next, we can create a new React component to render our JSON. We can call it RecursiveProperty. The reason is that it will render a single JSON property and its value when it reaches the base case.

Our component and file structure would look like this.

import * as React from 'react';

interface IterableObject {
  [s: number]: number | string | boolean | IterableObject;
}

interface Props {
  property: number | string | boolean | IterableObject;
  propertyName: string;
  rootProperty?: boolean;
  excludeBottomBorder: boolean;
}

const RecursiveProperty: React.SFC<Props> = props => {

  return(
    <div>Our future component</div>
  );
}

export default RecursiveProperty;

We can now render this component in App.tsx.

import * as React from 'react';
import './App.css';

import logo from './logo.svg';
import RecursiveProperty from './RecursiveProperty';

class App extends React.Component {
  public render() {
    return (
      <div className="App">
        <header className="App-header">
          <img src={logo} className="App-logo" alt="logo" />
          <h1 className="App-title">Welcome to React</h1>
        </header>
        <div className="App-intro">
          <RecursiveProperty property={testJson} propertyName="Root Property" excludeBottomBorder={false} rootProperty={true}/>
        </div>
      </div>
    );
  }
}

export default App;

const testJson = ...

I removed text-align: center from App.css and added margin: 0 auto and width: 60% to .App-intro class to nicely center our list.

Next, we need to write our conditions. The component must check if the property is a leaf (the last node in the hierarchy tree). If it is, it will render the property name and its value. If not, it will recursively call the component again with the next hierarchy level passed as the property.

We will create a container for each property so we can add a little styling (using styled-components). The container will have a left margin set so that each hierarchy level is a little more indent than the previous.

In this case, we will only try to render the properties which are the leaves. With our JSON, it will render only "It isn't a leaf", because the root of a JSON document is an iterable object, which we will handle later. We know that the leaves must always be one of the three basic JSON types - boolean, string or number.

import * as React from 'react';
import styled from 'styled-components';

interface IterableObject {
  [s: string]: number | string | boolean | IterableObject;
}

interface Props {
  property: number | string | boolean | IterableObject;
  propertyName: string;
  rootProperty?: boolean;
  excludeBottomBorder: boolean;
}

const RecursivePropertyContainer = styled.div`
  padding-top: 10px;
  padding-left: 3px;
  margin-left: 10px;
  ${(props: { excludeBottomBorder: boolean }) =>
    props.excludeBottomBorder ? '' : 'border-bottom: 1px solid #b2d6ff;'}
  color: #666;    
  font-size: 16px;
`;

export const PropertyName = styled.span`
  color: black;
  font-size: 14px;
  font-weight: bold;
`;

const RecursiveProperty: React.SFC<Props> = props => {
  return (
    <RecursivePropertyContainer excludeBottomBorder={props.excludeBottomBorder}>
      {props.property ? (
        typeof props.property === 'number' ||
        typeof props.property === 'string' ||
        typeof props.property === 'boolean' ? (
          <React.Fragment>
            <PropertyName>{camelCaseToNormal(props.propertyName)}: </PropertyName>
            {props.property.toString()}
          </React.Fragment>
        ) : (
          "It isn't a leaf"
        )
      ) : (
        'Property is empty'
      )}
    </RecursivePropertyContainer>
  );
};

const camelCaseToNormal = (str: string) => str.replace(/([A-Z])/g, ' $1').replace(/^./, str2 => str2.toUpperCase());

export default RecursiveProperty;

The camelCaseToNormal method is pretty self-explanatory, it converts camel case text to normal text with spaces.

Next, we need to recursively call the component again with the next level. We have two ways to represent a list of data in JSON - an Array of objects, or an iterable object with key/value pairs. For both cases, we need to map the properties to a new RecursiveProperty.

If we have an iterable object, we will use Object.values() method to get us an array of values (it is an ES7 method, so be sure to include it in the lib property in tsconfig.json). For passing the property names to the children we will make use of Object.getOwnPropertyNames() method. It returns an array of property names and we can make a safe access to the specific name with the index provided by the .map() method. What's great about this method is that it also works with arrays, returning the indexes instead of property keys.

Our component return() would now look like this.

return (
  <RecursivePropertyContainer excludeBottomBorder={props.excludeBottomBorder}>
    {props.property ? (
      typeof props.property === 'number' ||
      typeof props.property === 'string' ||
      typeof props.property === 'boolean' ? (
        <React.Fragment>
          <PropertyName>{camelCaseToNormal(props.propertyName)}: </PropertyName>
          {props.property.toString()}
        </React.Fragment>
      ) : (
        Object.values(props.property).map((property, index, { length }) => (
          <RecursiveProperty
            key={index}
            property={property}
            propertyName={Object.getOwnPropertyNames(props.property)[index]}
            excludeBottomBorder={index === length - 1}
          />
        ))
      )
    ) : (
      'Property is empty'
    )}
  </RecursivePropertyContainer>
);

Now it would be great if we could collapse and expand the nested objects and only display the leaf values for the initial render.

We can make a new component for that called ExpandableProperty.

import * as React from 'react';
import styled from 'styled-components';

export const PropertyName = styled.div`
  color: #008080;
  font-size: 14px;
  font-weight: bold;
  cursor: pointer;
`;

interface Props {
  title: string;
  expanded?: boolean;
}

interface State {
  isOpen: boolean;
}

export default class ExpandableProperty extends React.Component<Props, State> {
  state = {
    isOpen: !!this.props.expanded
  };

  render() {
    return (
      <React.Fragment>
        <PropertyName onClick={() => this.setState({ isOpen: !this.state.isOpen })}>
          {this.props.title}
          {this.state.isOpen ? '-' : '+'}
        </PropertyName>
        {this.state.isOpen ? this.props.children : null}
        {React.Children.count(this.props.children) === 0 && this.state.isOpen ? 'The list is empty!' : null}
      </React.Fragment>
    );
  }
}

We can now wrap our .map() method in this component so it can be expanded when desired.

return (
  <RecursivePropertyContainer excludeBottomBorder={props.excludeBottomBorder}>
    {props.property ? (
      typeof props.property === 'number' ||
      typeof props.property === 'string' ||
      typeof props.property === 'boolean' ? (
        <React.Fragment>
          <PropertyName>{camelCaseToNormal(props.propertyName)}: </PropertyName>
          {props.property.toString()}
        </React.Fragment>
      ) : (
        <ExpandableProperty title={camelCaseToNormal(props.propertyName)} expanded={!!props.rootProperty}>
          {Object.values(props.property).map((property, index, { length }) => (
            <RecursiveProperty
              key={index}
              property={property}
              propertyName={Object.getOwnPropertyNames(props.property)[index]}
              excludeBottomBorder={index === length - 1}
            />
          ))}
        </ExpandableProperty>
      )
    ) : (
      'Property is empty'
    )}
  </RecursivePropertyContainer>
);

Finally, we can see it in action!

Voilà, we just made something useful! Recursion works pretty well with React and it is a great tool which I will surely make more use of in the future. I hope I encouraged you too to use it as well, it doesn't bite!

You can find the source code at react-recursive-component

Cheers!