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 give it a try.

Also, among these I used pipe which composes each function in order

as the main method.

Composing the functions is the main work but

I didn't use compose because

compose basically does its work

backwards,

so I did not think it would be natural to read them.

So I used pipe instead

so using this composition

I wrote the reducer exiting the grid earlier

Here, select label and select type

and select grid are separated like this. And there is reducer for each as well.

This reducer

combining and finally made a reducer called

exitGrid. And each of the reducers

could be mapped in the action.

Seeing each reducer like this individually

as a separate function and writing them like this.

eventually rather than a switch

a reducer used to map formation

seemed to be better for writing. So that's why I wrote it like this.

The mapping formation actually

is used more often these days.

To show you more of

how it's processed in the store

the reducer map called switch reducer

makes a function that selects

a reducer map for the action type. By using that, we

finally make a root reducer.

The code was simply written in that formation.

However, when you look here,

it's going the same from root reducer to state action.

According to the action type,

the selected reducer does not need the action type's information.

So we additionally made a change to pass the payload.

So according to this here,

by not receiving the action but receiving the payload only,

the code became more simple.

The method I used in this process

is to combine all the states in one

and writing each of the many reducers.

Then I thought of a chapter I saw while studying

That is, 'Few data structures, many operations'.

That's how it was translated in Korean.

It was that quote.

Thinking, 'Would this be what that means?',

I got the grasp of it as I wrote the code.

When you see the writing of the reducer exiting this grid,

The exitGrid on the very bottom,

you have to use it by putting only one factor of each function,

so the select label

the select labels or

select label type, select grid, each reducer is all curried.

Curry, as you see in the example code,

if you surround a function with a curry,

you can practice the factor to the function in order

and you can apply it all at once.

As you see here,

As you see here,

in the first item, the count and the list are in order.

If you change that,

the same code

as you can see on the bottom,

now needs a placeholder.

When you use a function called curry,

the first 10

when you select the first 10 items,

if you receive the count first and get the list later,

it's natural to add in the factor 10 first.

However, when the order is reversed,

as to set it up first,

you add in the placeholder.

From this function composition

I found out that the order of the factors matter.

So here, functional programming

connects the various functions

and it's written to pass down the data there.

When you see the one I wrote, I made the state as one