# Function Composition

You actually have already seen some Function Composition in previous chapters, like higher-order function, `map`, `fold` and Currying. In that example, `map` is composited from `fold` and `reverse`.

This is the functional conception, compositing new function from the functions we already have. As shown in the figure above, `(g.f)(x)` is equivalent to `g(f(x))`, which is a function composited from `f` and `g`. In the case of `map`, which implemented in previous section, is equivalent to `(reverse.fold)(list)`.

### compose

Eweda provides us a convenient `compose` function.

``````var gh = E.compose(f, g)
``````

We have talked about composition, currying, so right now I can explain clearly why choosing Ewada over Underscore.js.

Supposing I need to find out all elements where its `completed` equals `true` in a list, and sort them by `id`.

In underscore, you may write some thing like this:

``````_(tasks)
.chain()
.value();
``````

This code doesn't look like functional, it likes object-oriented, with a bunch of method that return it self.

``````_.sortBy(_.filter(tasks, task => task.completed===true), task => task.id)
``````

Well, it looks better now. But why we didn't choose use underscore, but use Eweda:

``````E.compose(E.sortBy(task=>task.id), E.filter(task=>task.completed===true))(tasks)
``````

It seems that the code doesn't make any difference, it just use `compose`.

However, the big difference here is, in `E.compose`, `tasks` is the final parameter passed into `E.compose()`, while, in `_.sortBy`, `tasks` is a fixed parameter of `_.filter`, which means it's one time only composition. Howerver, `E.compose` has already compose functions before accepting data, so you still have chance to reuse it for other data, or compose it into other function.

If you haven't seen the benefit of this, let's take a look at the example. Suppose we have a list `groupedTasks` which contains few group of `tasks` lists, what I want to do is to find out the elements of `completed === true`, and sort them by `id` in each group. the data will look simply like this:

``````[
[{completed:false, id:1},{completed:true, id:2}],
[{completed:false, id:4},{completed:true, id:3}]
]
``````

In underscore, we write:

``````_.map(groupedTasks, tasks => _.sortBy(_.filter(tasks, task => task.completed===true), task => task.id))
``````

I am not sure whether you can understand it or not, anyway I can not understand it.

While in more functional way, we'd write:

``````var completedAndSorted = E.compose(E.sortBy(task=>task.id), E.filter(task=>task.completed===true))
// now i got my tasks updated, and I wanna sort it again
``````

Have you notice that the thinking of processing data is totally different.

While we doing function composition, functions are automatic currying, so that they can be composited at will, then we use the composed function to deal with the data. This is functional composition conception. However, in underscore, either we keep intermediate data in Object, applying various functions on target by chaining approach(this is called Flow-Base programming, but I think it's same thing as Monad I'll cover in next chapter), or we use nested functions passing the target through each level.

Similar to `compose`, Eweda has a function called `pipe`, which executes function in opposite direction of `compose`. Like `pipe(f, g)`, Eweda executes `f` at first, then passes result to `g`. Does this remind you of `pipe` in bash?

``````find / | grep porno
``````

It's actually `pipe(find, grep(porno))(/)` isn't it.

Yes, they are all the same. And this execution direction is more readable for human brain compiler.

source code