
Async friendly transformation middleware for Redux - papapopper
https://github.com/contrarian/redux-transform
======
zackify
Do most people not have good control over the api’s they use?

I feel like I see many projects like this with the goal of transforming data
or making more requests and things after each request (redux-saga).

If you have control over the api you are interacting with, most of these
things aren’t needed. Plus, less work done on the client the better, right?

~~~
truetuna
Based on my personal experience, sometimes even if the API is yours, making
changes can be difficult. The example I first think of is my last company.

We had a backend and frontend team, both working on the same product but the
two teams disagreed a lot and would take weeks to make a small change even if
it wasn't a breaking change.

To add to it all, there wasn't a standard to deprecating APIs so even a simple
key rename could cause everything to blow up. Things weren't fun so I can see
the need for these kinds of tools.

------
jschrf
Looks neat, but I'm having trouble understanding the value proposition here.

Why do I need a framework on top of another framework to manage
asynchronicity? Async should be figured out by now.

Is this just "enterprise Java" again?

~~~
tengbretson
I would argue that its the opposite. It seems that redux is adamantly
resisting the temptation to expand its scope and is sticking to its original
promise of being a state container that undergoes state transitions via the
composition of functionally-pure reducer functions and nothing more.

~~~
halayli
Yes redux is a store but it has middlewares like redux-thunk, redux-promises,
and promises that lets you manage all the async actions you require.

------
acemarke
Looks useful. Still not used to reading TypeScript, but I get the general idea
and implementation.

I'll definitely add this to my Redux addons catalog in the next update!

~~~
papapopper
There is an example app written in JS: [https://github.com/contrarian/redux-
transform/tree/master/ex...](https://github.com/contrarian/redux-
transform/tree/master/examples/js)

~~~
molszanski
The docs is in TS. I am not used to reading and understanding fancy TS. This
is a problem.

~~~
papapopper
Noted. I may add seperate JS documentation.

------
papapopper
redux-transform is a general transformation middleware.

You can use it to transform an API response. But more intriguingly you can use
APIs to transform an action.

~~~
davnicwil
What's the advantage of using this over:

1) transforming actions directly inside action creators 2) transforming
responses inside redux-thunk thunks or redux-promise-middleware promises

Maybe I'm not getting it, but with the above methods I can already transform
my actions and responses. I can also use async/await if I want to mix async
and sync logic in a readable way. This just seems to layer an abstraction over
that sort of thing, but for what benefit? Is this actually intended to be an
alternative to redux-thunk or redux-promise-middleware, and not used in
conjunction with them?

Genuinely asking for information and not trying to be critical, sometimes it's
hard to see use cases and benefits of new patterns when you first encounter
them :-)

~~~
papapopper
redux-transform: 1\. lets you transform an arbitrary number of fields with an
arbitrary number of transformations 2\. runs the transformers for each field
concurrently

It is true that there are other opportunities to transform actions, but you
would have to implement the logic to perform arbitrary transformations. You
can use async/await to mix async and sync logic, but you will have to be
careful about concurrency. With redux-transform, you can just focus on
implementing transformers, and specifying which ones to perform.

redux-transform is intended to complement other middleware. You can use it in
conjunction with both redux-thunk and redux-promise.

