Placeholder Image

字幕表 動画を再生する

  • Hello.

  • 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

  • and by chaining the various reducers,

  • I made it pass down like that.

  • But,