Does it support server render?

[kamechb]

import { Store, createState, withProps } from '@ngneat/elf';

interface AuthProps {
  user: { id: string } | null;
}

const { state, config } = createState(withProps<AuthProps>({ user: null }));

const authStore = new Store({ state, name: 'auth', config });

Looks like we create a store globally, if we run it in server side, all of the requests will share the same store which will make the data conflict?

[NetanelBasal]

How it's globally? It's inside a module.

[kamechb]

yep it's in a module, but the module will only run once right, all requests will share the same authStore instance no? for example:
request 1:

doAsyncRequest().then(authStore.update())

request 2:

doAsyncRequest().then(authStore.update())

The authSotore instance should be same in request 1 and 2, because all requests are served by same node process right?

[kamechb]

so for server render, it may cause issues, request 1 can be from user 1, and request 2 can be from user 2, but they share the same authStore, user 1 request probably render the data from request 2 if the rendering happens after request 2.

[NetanelBasal]

I am not sure what is your use case. Do you want to use it in the server? For what?

[kamechb]

I have an app using angular with server render support. The code has to run in node to render the page first to serve the user request, and after response returns, the client hydrates the page. So the store code will run in both node & browser. This is a general requirement for ssr render app whatever framework you use. I remember what redux did for react is wrapping the app in a "Provider" to let the components access the store instead of importing the store directly.

[NetanelBasal]

Yes, I'm familiar with this proccess. I don't think there should be an issue. You can try and let me know.

[kamechb]

okay I will setup a demo to have a try. Thanks!