There are several changes required in order for MetaMaps to be accepted into the MetaGame codebase. While the most important tasks involve QA and formatting. This is also a good time to augment the existing implementation with changes we are planning in the future.
The Maps
table needs to be regenerated. It would be a good idea to reset all diffs in Hasura and update it to use Player.id instead of an Ethereum address. The address that is pulled from 3box should be used to find the player's id on MetaGame.
-
Reset all diffs in Hasura.
-
Have maps associated with
Player.id
instead of an Ethereum address. -
Map data should be
json
instead oftext
.
The current implementation of Redux needs to be updated to: https://redux-toolkit.js.org/. There are general refactors required such as needing more efficient mappings for component renders. This would be pretty important for larger map datasets.
-
Refactor to redux toolkit.
-
Improve component renderings such as not have components inside redux stores.
We should be utilizing the @metafam/ds component libraries. We may want to also implement new context specific components for example the shapes and context menus used in metamaps.
-
Update and migrate components to
@metafam/ds
. -
Copy theme elements from other MetaGame's designs. Can use Figma as a reference: https://www.figma.com/file/RWVfMGvXDAX74fQexze8uO/Meta-Game-Copy-Copy?node-id=58%3A2
-
Improve overall code structure to
jsx/tsx
.
As per comments from @heterotic, we should have a z component. Where one can toggle the z index of the map. This would be a +/- button with an input at the top of the map.
-
Create a
z
layer for maps. -
Maps can be toggled with a
-/+
button at the top with a number input. -
Map renders are based on the
z
layer.
However, instead of all of the additional trappings that are presented in the Voyager, we want it to look like the MetaGame, use the design elements from our own repo, and instead of displaying the full schema logic, just show the links between tables as single edges, and show the tables as labeled square.tsx objects, which on-click load a popup.tsx that contains the schema details for that table... Finally, we do not need to load the object called 'query_root' here, which I believe is an abstraction based on all of the actual tables spelled out in the diagram... this will further reduce the number of edges displayed in the initial load of the schema data, and clean things up a bit visually to leave space
for the query builder...