reactjs-flux

Automatic redirect after login with react-router

回眸只為那壹抹淺笑 提交于 2019-11-27 08:11:54
I wanted to build a Facebook login into my react/react-router/flux application. I have a listener registered on the login event and would like to redirect the user to '/dashboard' if they are logged in. How can I do that? location.push didn't work very well, except after reloading the page completely. Michelle Tilley React Router v0.13 The Router instance returned from Router.create can be passed around (or, if inside a React component, you can get it from the context object ), and contains methods like transitionTo that you can use to transition to a new route. React Router v3 This is what I

Flux Dispatch.dispatch(…): Cannot dispatch in the middle of a dispatch

有些话、适合烂在心里 提交于 2019-11-27 08:03:36
My code https://gist.github.com/ButuzGOL/707d1605f63eef55e4af So when I get sign-in success callback I want to make redirect, redirect works through dispatcher too. And I am getting Dispatch.dispatch(...): Cannot dispatch in the middle of a dispatch. Is there any hack to call action in the middle ? I don't see where in the gist that you posted you are doing the redirect. I only see the AUTH_SIGNIN and AUTH_SIGNIN_SUCCESS actions, and they look pretty straightforward. But no, there is no hack to create an action in the middle of a dispatch, and this is by design. Actions are not supposed to be

Flux: waitFor specific event

↘锁芯ラ 提交于 2019-11-27 07:13:54
问题 I'm trying to understand how to resolve dependencies among stores. The problem is I have a comprehensive data tree, which need to be fetched from server with the chain of request that depends one on another. PROBLEM: waitFor seams not to be supposed for async requests. Suppose next event chain: NEED_A (look at StoreA ) NEED_B (look at StoreB ) Here StoreB do AppDispatcher.waitFor([StoreA.dispatchToken]) . But actually we want to wait for GET_A SOME_OTHER_ACTION (look at StoreA ) The third

How to download fetch response in react as file

这一生的挚爱 提交于 2019-11-27 05:24:31
问题 Here is the code in actions.js export function exportRecordToExcel(record) { return ({fetch}) => ({ type: EXPORT_RECORD_TO_EXCEL, payload: { promise: fetch('/records/export', { credentials: 'same-origin', method: 'post', headers: {'Content-Type': 'application/json'}, body: JSON.stringify(data) }).then(function(response) { return response; }) } }); } The returned response is an .xlsx file. I want the user to be able to save it as a file, but nothing happens. I assume the server is returning

Test a React Component function with Jest

断了今生、忘了曾经 提交于 2019-11-27 05:17:22
问题 Original First of all, I am following the Flux architecture. I have an indicator that shows a number of seconds, ex: 30 seconds. Every one second it shows 1 second less, so 29, 28, 27 till 0. When arrives to 0, I clear the interval so it stops repeating. Moreover, I trigger an action. When this action gets dispatched, my store notifies me. So when this happens, I reset the interval to 30s and so on. Component looks like: var Indicator = React.createClass({ mixins: [SetIntervalMixin],

Pass object through Link in react router

做~自己de王妃 提交于 2019-11-27 01:40:58
Is it possible to pass an object via Link component in react-router? Something like: <Link to='home' params={{myObj: obj}}> Click </Link> In the same way as I would pass props from the Parent to Child component. If it's not possible what is the best way of achieving this: I have a React + Flux app, and I render the table with some data. What I am trying to do is when I click on one of the rows it would take me to some details component for this row. The row has all of the data I need so I thought it would be great if I could just pass it through Link . The other option would be to pass the id

Should flux stores, or actions (or both) touch external services?

♀尐吖头ヾ 提交于 2019-11-26 21:11:05
Should the stores maintain their own state and have the ability to call network and data storage services in doing so ...in which case the actions are just dumb message passers, -OR- ...should the stores be dumb recipients of immutable data from the actions (and the actions be the ones that fetch/send data between external sources? Store in this instance would act as view-models and would be able to aggregate / filter their data prior to setting their own state base on the immutable data they were fed by the action. It seems to me that it should be one or the other (rather than a mix of both).

How do you manage asynchronous Store operations with Flux?

纵饮孤独 提交于 2019-11-26 19:24:46
问题 In the Facebook talk on the Flux architecture, Jing mentions at 12:17 that the dispatcher enforces that no actions can be dispatched until the current action is fully processed by the stores. The dispatcher here is the main piece that enforces that there's no cascading effects; once an action goes into the store, you can't put another one in until the stores are completely finished processing it. My question, then, is how do you properly deal with long-running asynchronous operations that

At what nesting level should components read entities from Stores in Flux?

心已入冬 提交于 2019-11-26 15:05:36
问题 I'm rewriting my app to use Flux and I have an issue with retrieving data from Stores. I have a lot of components, and they nest a lot. Some of them are large ( Article ), some are small and simple ( UserAvatar , UserLink ). I've been struggling with where in component hierarchy I should read data from Stores. I tried two extreme approaches, neither of which I quite liked: All entity components read their own data Each component that needs some data from Store receives just entity ID and

Where should ajax request be made in Flux app?

陌路散爱 提交于 2019-11-26 14:49:42
I'm creating a react.js application with flux architecture and I am trying figure out where and when a request for data from the server should be made. Is there a any example for this. (Not TODO app!) I'm a big proponent of putting async write operations in the action creators and async read operations in the store. The goal is to keep the store state modification code in fully synchronous action handlers; this makes them simple to reason about and simple to unit test. In order to prevent multiple simultaneous requests to the same endpoint (for example, double-reading), I'll move the actual