MetaMaps formalized spec

METAMAPS.md

Overview

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.

Requirements

Hasura + Table Structure

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.

Tasks

• Reset all diffs in Hasura.

• Have maps associated with Player.id instead of an Ethereum address.

• Map data should be json instead of text.

React/Redux Refactor

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.

Tasks

• Refactor to redux toolkit.

• Improve component renderings such as not have components inside redux stores.

Updating Component Libraries

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.

Tasks

• 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.

Z Component

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.

Tasks

• 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.

The 2nd Class should run the query passed by the 1st class, and the results should be published to a JSON string, and then pushed to the metamap in the 3rd class to be displayed in a simplified manner similar to the image that was rendered in https://apis.guru/graphql-voyager/ from our query result shown here:

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...

Once we get that far, we can talk more about what additional tools we will need to create a 'component builder' and/or 'query builder' for the metamaps <3