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.
The 3rd class in the parsing engine is a visualizer for the schema data provided in the JSON string from the 2nd class. This class also contains any tools needed for visually constructing the queries that produce the data to be displayed in the view of the metaMaps rendering engine, and runs the queries prior to sending the results back to the map for rendering <3 Basically, we need something like this: https://apis.guru/graphql-voyager/ <3 https://github.com/APIs-guru/graphql-voyager ....perhaps showing each table as a stripped down rectangle/square with the basic table/array data from the stored JSON (tableName, # col, # row) , but allowing the full field data to be shown/hidden on a click behavior. Also, in addition to displaying the schema information visually, the class should be able to allow a user to select elements (nodes and edges) to be displayed in the map and construct the queries that will poll data from the datasources to be displayed by the rendering engine. Whenever the map is running a view and has passed the check in the 2nd class, this visualizer should be accessible as a pull out drawer from the map. Whenever an element is selected from the drawer and dragged over to the view of the map, this class should check the current elements displayed in the map as edges or nodes and add the newly selected element to the query so that data from the new element can be added in the map rendering engine. Finally, there should be a way to set whether a filter is required for a particular element when loaded, and the type of filter that is to be added (type, multitype, specific value, multi-value, value range, etc...). The metadata used by the tools and/or the current query to poll data from the datasources for the map rendering engine should be saved both in a JSON string, and optionally as part of the saved view in the Map table in hasura.