|
1 | 1 | # Respond Framework
|
2 |
| -Think of your app in terms of _states_, not _routes_ or _components_. Connect your components and just dispatch _Flux Standard Actions_! |
3 | 2 |
|
4 |
| -**Respond Framework** is the successor to [redux-first-router](https://github.com/faceyspacey/redux-first-router). |
| 3 | +Think of your app in terms of _states_, not _routes_ or _components_. Connect |
| 4 | +your components and just dispatch _Flux Standard Actions_! |
| 5 | + |
| 6 | +**Respond Framework** is the successor to |
| 7 | +[redux-first-router](https://github.com/faceyspacey/redux-first-router). |
5 | 8 |
|
6 | 9 | ## Motivation
|
7 |
| -To be able to use Redux *as is* while keeping the address bar in sync. To achieve *bi-directional mapping* between the address bar and Redux actions. This way, changing the address (also via back/forward) dispatches an action, and dispatching an action changes the address. Paths are defined as actions, and path params and query strings are handled as action payloads. |
8 | 10 |
|
9 |
| -**Respond Framework** also seeks to *avoid* the following obstacles: |
| 11 | +To be able to use Redux _as is_ while keeping the address bar in sync. To |
| 12 | +achieve _bi-directional mapping_ between the address bar and Redux actions. This |
| 13 | +way, changing the address (also via back/forward) dispatches an action, and |
| 14 | +dispatching an action changes the address. Paths are defined as actions, and |
| 15 | +path params and query strings are handled as action payloads. |
| 16 | + |
| 17 | +**Respond Framework** also seeks to _avoid_ the following obstacles: |
10 | 18 |
|
11 |
| -* Rendering from state that doesn't come from Redux |
12 |
| -* Dealing with the added complexity from having state outside of Redux |
13 |
| -* Cluttering components with route-related code |
14 |
| -* Large API surface areas of frameworks like `react-router` and `next.js` |
15 |
| -* Routing frameworks getting in the way of optimizing animations (such as when animations coincide with component updates) |
16 |
| -* Having to do route changes differently in order to support server-side rendering |
| 19 | +- Rendering from state that doesn't come from Redux |
| 20 | +- Dealing with the added complexity from having state outside of Redux |
| 21 | +- Cluttering components with route-related code |
| 22 | +- Large API surface areas of frameworks like `react-router` and `next.js` |
| 23 | +- Routing frameworks getting in the way of optimizing animations (such as when |
| 24 | + animations coincide with component updates) |
| 25 | +- Having to do route changes differently in order to support server-side |
| 26 | + rendering |
17 | 27 |
|
18 | 28 | ## Usage
|
19 | 29 |
|
20 | 30 | ### Install
|
| 31 | + |
21 | 32 | `yarn add @respond-framework/rudy`
|
22 | 33 |
|
23 | 34 | ### Basic example for React
|
@@ -165,7 +176,9 @@ export {
|
165 | 176 |
|
166 | 177 | The source code for this example can be found [here](./examples/react).
|
167 | 178 |
|
168 |
| -Also see the [boilerplate project](./packages/boilerplate) and the (partly outdated) [documentation](./packages/rudy/docs). |
| 179 | +Also see the [boilerplate project](./packages/boilerplate) and the (partly |
| 180 | +outdated) [documentation](./packages/rudy/docs). |
169 | 181 |
|
170 | 182 | ## License
|
| 183 | + |
171 | 184 | [MIT](LICENSE)
|
0 commit comments