omnistac / zedux Goto Github PK

While checking out the example pages, I get the following error in Firefox (but not Chrome):

TypeError
can't access property "toUpperCase", fn[0] is undefined
generateReactComponentId/_a<@https://b5upgd.codesandbox.io/node_modules/
zedux/react/dist/cjs/classes/IdGenerator.js:83:13
generateReactComponentId@https://b5upgd.codesandbox.io/node_modules/
zedux/react/dist/cjs/classes/IdGenerator.js:78:14
useReactComponentId/<@https://b5upgd.codesandbox.io/node_modules/
zedux/react/dist/cjs/hooks/useReactComponentId.js:16:62
mountMemo
https://b5upgd.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:17225:19

The Live Sandbox examples in the docs work fine, however: https://omnistac.github.io/zedux/docs/walkthrough/quick-start

A bit of triage indicates that it's likely because DEV mode is on while in Firefox in CodeSandbox, although I wasn't able to glean insights into why

In the documentation, the Edit this page link points to the incorrect place.

For example:

Currently it links to: https://github.com/Omnistac/zedux/tree/master/docs/about/introduction.mdx

I recommend it is linked to: https://github.com/Omnistac/zedux/edit/master/docs/docs/about/introduction.mdx

Zedux Version

1.1.1

Description

I'm facing some strange useAtomSelector bug where in certain circumstances selector doesn't update when the selected value changes. If I replace selector with an ion which has the same getter then it works. Another workaround is to put forceUpdate (from useReducer) right after I update the global atom's state in my component.

Reproduction

Can't reproduce the issue in sandbox.
The project I'm working on isn't open source, so there's no public repo. Is it possible to share code with you privately? If yes, please send me your email here or in Telegram (@crabvk).

Zedux Version

1.2.1. Also tested 1.2.0.

Description

When you use setInternals to work across windows there appears to be a limitation that the same component cannot be used in multiple windows. Eg if I have a WindowFrame wrapper component that accesses a theme atom via useAtomState or useAtomValue to update its theme and I open 3 different windows that contain this WindowFrame component, only one of them will receive live updates. If, instead, each window uses a unique react component and gets the theme from the atom separately, it works fine.
This appears to be due to how useAtomInstance generates a key using const dependentKey = useReactComponentId(). This appears to make the keys non-unique across windows. One way to see this is likely the case is to see that the graph only seems to have the number of dependents that matches the maximum instance count in a given window.

This is causing us quite an issue as our app lets users pop out different parts of dashboards and we chose Zedux specifically because it has great multi-window support (it's great generally, but this was the deciding factor), but as we've begun standardizing and abstracting to generic components this issue has caused parts of our WIP app to stop live updating.

Below I've included a small reproduction using window.open. In our real app we use OpenFin, but the issue is the same either way. I guess ideally we'd be able to inject the window name or uuid into the dependentKey.

Reproduction

Please see this demo in StackBlitz (I had trouble getting windows to work well in codesandbox). Note that I disabled strict mode and that re-enabling it causes a slightly different behavior. I've tried to add notes in the comments and on the UI itself to explain how to trigger the issue, but am more than happy to try and make clearer.

https://stackblitz.com/edit/vitejs-vite-q37ggg?file=package.json

Thanks for any help or advice you can give on this.

Zedux Version

1.2.0

Description

If I have a Zedux store that has an object structure and I either pass in a type for the store as a generic or Zedux infers it, there is inadequate type-safety to prevent values getting unset. This happens because setStateDeep needs to be able to have any key be optional. So I can currently use this to set what should be a required field as undefined: store.setStateDeep({someRequiredField: undefined});. This will actually set the value to be undefined.

So I would assume that either all values for the store should be possibly undefined, or setStateDeep should ignore undefined values when merging. Below is a contrived example, in our case it was happening because we were getting one value from somewhere else and using it in setStateDeep.

Reproduction

import type { AtomStateType } from '@zedux/react';
import { atom, injectStore } from '@zedux/react';

type ExampleAtomState = {
  someArray: Array<number>;
  saveStatus: 'idle' | 'saving' | 'success' | 'error';
};

const defaultExampleAtomState: ExampleAtomState = {
  someArray: [1],
  saveStatus: 'idle',
};

const errorsIfUndefined = (v: string) => v;

export const exampleAtom = atom('example', () => {
  const store = injectStore<ExampleAtomState>(defaultExampleAtomState);
  console.log('store.getState()', store.getState());
  store.setStateDeep({ saveStatus: undefined });
  console.log('store.getState()', store.getState());
  const status = store.getState().saveStatus;
  console.log(errorsIfUndefined(status));
  return store;
});

So above I would either expect an error in TS on this line: console.log(errorsIfUndefined(status)); as I would have expected the inferred type of the store to essentially be a Partial<>, or that store.setStateDeep({ saveStatus: undefined }); is basically a no-op. I was thinking the former, but it does have the downside of always having to do extra checks that the value exists even if you aren't using setStateDeep anywhere. Could be better DX for Typescript users to prevent setting undefined in setStateDeep.

Zedux Version

v1.2.0-rc.1

Description

1. Pressing Ctrl+K doesn't open the search modal as the search button suggests.
2. The search feature doesn't work returning "Internal Server Error" on any input.

Zedux Version

"@zedux/react": "1.1.1",

Description

useAtomSelector doesn't trigger a re-render when used with useAtomContext.
But, any other re-render in the component will cause the selector to register and work as intended.

Try making a change in the code in the code sandbox, and you'll see it start to synchronize.

Reproduction

https://codesandbox.io/s/epic-snow-pxyvym?file=/src/App.js:0-1823