This is my first time doing a full-scale presentation so I'm really nervous.

As you can see, in this session,

I'm going to make a presentation about functional JavaScript.

It's not that I know functional Javascript that well

that I'm making a presentation.

Some of the traits of functional programming

that I've applied on real projects

and my experience of grasping it little by little, is what I want to share.

And that's why I'm here.

I'm a developer in a company called Lunit

that analyses medical images.

It's been 3 years since I started being a developer.

Before this, I worked in design.

It was 2016 when I just started learning how to program, three years ago.

There was a keyword that was very popular at the time.

That is 'React'.

React is a library that helps to make interfaces.

There would be some of you who haven't used it

but I'm sure everyone has heard of it before.

It's a library that people have been constantly giving love to.

And three years ago,

along with 'React', there was another keyword that arose.

That is 'Redux'

MobX is used a lot recently too,

and it's compared with React Hooks a lot too.

At the time Redux was thought to be very innovative.

So it was in the center of the stage.

Redux is used with the library that makes UI

and it's a tool that maintains state in Javascript.

As you can see on the right,

it separates the state and the UI interface on the bottom

and makes the state into action. That is the basic structure of Redux.

With Redux,

it is not as fast but

there's a keyword that slowly appeared.

That is 'functional programming'.

Dan Abramov, who made Redux,

got the idea from Elm, a functional language,

and made it. So with Redux,

the keyword 'functional' was gradually mentioned.

At the time, I was a beginner in development.

So it was too hard for me to get the grasp of what it meant.

Although I didn't understand all the basic concepts of Redux,

using Redux by itself

was very interesting and fun.

When you make apps following the structure of Redux,

eventually, the interests were all separated

and the codes, including the components, became very neat.

That's why I liked Redux very much.

Because of my interest for Redux,

in the case of functional programming,

I looked at it with vague curiosity and admiration.

As time passed and I got used to the job,

my curiosity for functional programming was revived

and I started to study with my co-workers.

In this study,

the basic concepts of functions, to use a pure function,

to prevent additional effects,

to use preface grammars,

I was able to understand these basic concepts.

I also got to know about Monad and Reactive Programming.

The most memorable thing that I remember from this study

was actually the advantages of using functional programming.

Since it connects simple pure functions,

it's less likely to have errors in a function, so it's more stable.

And it's more likely to be reused since it connects small functions.

And it's easy to understand higher logic. These three were the advantages.

It was very appealing at the time

but after studying,

other co-workers and I

still didn't catch the grasp on

what exactly the functionals were.

I think this was because when we wrote for a real project,

this was the limitation of what we could apply

from what we've learned while studying.

Well, we could do more

but when we copied,

there was feedback that it didn't seem like functional programming.

So this was mostly what we wrote.

So we... studied functional programming but it was still vague.

Just understanding the concepts, a year passed.

I went to a new company

and started a new project.

To show you simply, this is the app.

One moment.

Add a grid like this,

and from that cell slide,

which is the cancer cell

or the fat cell, is all marked.

It's the tool that helps process data.

Refactoring

this tool was the task given to me.

Because, before, only React and Canvas were applied

and it wasn't organized.

Using Redux,

I was given the task to refactor it.

Like I wrote originally,

I naturally used combineReducers

and wrote the code.

When using the combine reducer,

it takes the state of the reducer

and see it as each domain like DB

and it separates the reducer completely.

The connection between reducers can be made actions.

So let's say we are adding

a label to a display like this

I put together the key points here.

When you write a reducer to add a label like that

you need to use label type

and other information from grid reducer.

As the app gets more complex,

more information is going to be added.

When using combine reducer like this

in order to process this

you need to take information in the other reducer

and pass it onto the factors and parameters.

With more actions like these,

there is going to be more cases of having to pass onto the parameters.

Also, there was one other thing I was not happy with.

You can use a middleware when using redux,

and this middleware, takes care of ajax

or processes events that cause additional effects,

and loads other action

or processes loading other actions right away.

Let's say we are writing reducer that exits

the selected grid here,

after writing the reducer exiting the grid

it needs to be processed along with the other reducer

although there is no api call

in order to simply load other action

the code for middleware must be written.

And of course with more processes like these

unnecessary middleware code is going to increase.

So it's going to look like this.

So then we wondered

if there is another way to write it.

So we looked into redux documents

and there was a post called Beyond combineReducers.

It has been updated so it looks different from when I first saw it

but the basic information is the same.

Here, it talks about combine reducers, that

it can only cover simple cases.

And that there needs to be some kind of a customization?

or reducer logic is needed.

So I wanted to minimize having to pass factors into function

and write each reducer code separately

then in the redux middleware,

I wanted to write the reducer and customize it

so that it will only deal with additional effects.

These are the purposes I started the works with.

There was something else that helped with that

If you scroll down to the previous document

it introduces a library called reduce-reducers

as another method.

As you can see in the code here

it is a reducer function composition library

where you can execute different reducers

in order and finally make it into

one type of state.

This is the official document on reduce-reducers

I saw this format, and if I were to follow it exactly I would need to add a state

so I wanted to make it into a format I liked

by composing reducer like this

and tried writing it.

Actually I did not look into libraries composing reducers

closely at the time.

When you go through the documents in redux

there are so many libraries.

This is only part of the page

and there is a library called reducer ramda.

There are so many reducer composing libraries

and I wanted to just simply start with something I knew about so I chose ramda.

Ramda.js focuses on currying and composition and it is a functional library

as I remembered from studying before,

so I wanted to