Open pdfowler opened 6 years ago
Hi @pdfowler,
please, can you provide more info about and how to reproduce this issue?
Anyway, removing the SSR code is not recommended, if you don't need SSR I suggest you use something else like: https://github.com/facebook/create-react-app
Thanks for the reply. We're a bit too invested in the rfx-stack at this point, so we've taken an alternate approach. The problem manifests when two concurrent requests hit the server for two different logged in users. What appears to be happening is as follows:
fetchData
is called and begins executingfetchData
is called and begins executingfetchData
mutates the state of the app's mobx store, corrupting User A's request.I have tried several methods to separate out the stores on a per-request basis, but have had no success. The closest I got resulted in the MobX error complaining about having multiple stores.
Our solution for now has been to do the following:
fetchData
, set an empty object for window.__STATE
. The results in a quickly rendered app chrome including menu bar, and general look & feel.window.__STATE
and execute fetchData
on the client based on the client's jwt.While the root problem remains that an incorrect user's name or company may be rendered into the header, it eliminates the possibility of another user's (private) data being rendered in one of the main body components.
Your issue seems related to this one: https://github.com/feathersjs/authentication-client/pull/99
If so, this is my workaround (I'm using feathers buzzard
, not tested with the version used in this repo).
In the auth
store update the code of the jwtAuth
method as below:
jwtAuth({ token }) {
if (!isClient) {
app().set('accessToken', token);
return this.verifyToken(token)
.then(payload => this.loadUser(payload.userId));
}
return app()
.authenticate({ strategy: 'jwt', accessToken: token })
.then(response => this.verifyToken(response.accessToken))
.then(payload => this.loadUser(payload.userId));
}
That's the exact issue that gave us a great amount of hope last week, but after some initial success, we were still able to repro the issue. We're on feathers v3 buzzard as well.
We've tabled the issue for now and will revisit down the line. Thanks for digging a bit.
Also, I've got a big update to rfx that I'm queuing up in my repo that brings most of the libraries up to date - MobX 5, Feathers 3, Prettier, React Router 4 (still pending), etc. I've taken a lot of the things we've learned building a product on top of the stack and applied it to my repo. Once we move it over to our org's repo, we should be ready to submit a PR. You can see the changes here: https://github.com/pdfowler/rfx-stack/tree/feature/rfx_v2
@pdfowler Your updates are very appreciated.
Can the issue be reproduced also with the current repo?
I’ll see if I can reproduce it tonight ...
Any updates on this?
If you still have this issue, I just published a new repo which can be interested for you.
https://github.com/foxhound87/rfx-next
It's a new stack based on Next.js with all the functionalities of rfx-stack, like mobx support, rfx-core state mgmt, tachyons and Material UI 3.
The new app si pretty fast to develop and deploy compared to the rfx-stack.
@foxhound87 - We've been diagnosing (and fixing) some crazy SSR issues that happen with simultaneous requests. Basically, the second request corrupts the state of the MobX stores and all sorts of uncertainty results. (I'll be reaching out separately to get your input on that)
Where we are right now however is searching for a solution to disabling SSR for production - basically making it run like
web:dev
. We're having some trouble since the state and SSR stuff is so integral to the setup - everything we try has resulted in hard errors.The two main points we are trying to solve:
fetchData
on the components when the load client-sidesrc/web/ssr.js
to simply render everything client side.Thoughts?