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.
Each view in the map is defined by the data sources it is designed to load, the schemas extracted from that data source on load, and the design elements assigned to instances of the schemas from that data source as defined by the Player designing the view. The parsing engine driving the map needs three basic classes. The 1st class is a class that loads the data connections and data connection types (graphQL, *sql, API, etc) as well as any access protocol data that is required to establish the connection. The user should be required to complete this information the first time a new data source is loaded, but the default data source of the MetaGame hasura could be added as a connection available to a default view that we added as the initial row to the Map connection table(s). The connection data for a particular view could be stored in a user table as indicated in the Map tables so far, to manage permissions and the data source connection to load the initial schemas for the second class in the map parsing engine. The last part of the first class is a function to query the datasources based on their data type to extract the schemas from the data source. Once the schema information has been extracted for each data source in a view, it should first be added to cache in a JSON string, for use in the 2nd class in the map parsing engine.