expo
feat(map-set-redux): replace json viewer for redux dev plugin in orde…
@dev-plugin/redux is using an outdated json viewer which doesn't support maps and sets. I've replaced the library with one that does. Also, added superjson to keep the meta of the objects.
Even thought redux doesn't recommend Maps and Sets to be used, this plugin is also very useful for zustand which accepts these kind of values for state
@Kudo @byCedric while trying to understand why the data between the plugin and the web client wasn't transporting the maps and sets, I found the MessageFramePacker code and was thinking that we can use superjson there as a fallback. This way, any important meta is kept, since superjson supports more data types.
I can submit a PR if you think this would be a great addition to Expo.
https://github.com/flightcontrolhq/superjson?tab=readme-ov-file#examples-3
by coincidence, i was investigating #60 which has performance drop coming from the MessageFramePacker. i was thinking that performance is the key rather than flexibility.
ok, then it remains for each plugin to adjust accordingly? also cc'ing @dannyBies if you agree with the current change
ok, then it remains for each plugin to adjust accordingly?
right. i am still leaning toward leaving advanced serialization/deserialization inside plugins. for example, if people have Set/Map inside a js object. it would take more complex implementation to look into types in nested objects.