• Table of content
  • 🚀 Getting Started
  • 📚 Dependencies and ecosystem
  • 📔 Implementation

First, clone the repo to your local machine.

Then, install dependencies

npm install

In this demo, I used json-server as a mock server which supports some basic CRUD operations, so in order to get mock data, there is a prerequisit condition, you need to install the json-server

npm install -g json-server

Then you can simply run npm run server then npm start to run the project in your local environment

This project was started with Create React App and uses a standard tech stack:

• React
• Redux
• React-Router
• styled-components
• Storybook

Some small but powerful third party libs used in the project:

• selector library for redux
• loadable for code split
• json server to get a full fake REST API

I also used some utilities to standardize the code format and formalize the commit messages

prettier and commitlint respectively for code and commit message formatting, along with husky for automation based on git hooks.

This service is currently focusing on creating templates for a given parameter(configuration) in a game.

As a complete version of this service, this application will evolve into 2 main features.

1. Parameter Panel (the currnet feature implemented of the project)

   this feature will allow in house designers/admins to config different parameters(json schema based) of the game by creating/editing/deleting different sets of templates.
   

   Why creating templates not directly creating settings:

   The reason way I go with this way of implementation is that based on my knowledge, game settings could be a dynamic range of particular fields and as for how to combine those fields, it is better for the game client (game programmers, other BE services) to decide, not by the live opertors/designers who may potentially use this tool, a single souce of truth will be better and easier to manage

   So when i read the requirement, the first thing came to my mind is that those parameters would be generated by the game client as json schema then store in the BE and send to the FE to consume.

   Then the FE receives different parameters and will manipulate the values of an instance of a given parameter

   So that is why I didn't choose to create a form by applying a bunch of predefined fields and save it.

   Also, when it comes to things like A/B testing, the way I propsed here will also prevent us from doing a lot of repetitive work.

   Imagine when we want to apply to two different segmentation with different parameter values.

   If we go with creating settings on the fly, that means we need to create multiple same forms. it is more error prone.

   But if we directly got this schema from the BE then the user only need to enter the different values for the same parameter. It is quick and easy.
   

2. Editor Panel

   this feature will include an editor where it will consume templates greated from the parameter panel and will allow operators to directly apply those predefined template into the game.

1. permission

   e.g. a live ops operator could only use existing template but cannot arbitrarily create any random templates, all the template creation has to be validated by an admin.

2. A/B test

   can define different groups with different segmentation then apply different parameter template (config with different values)

Extra Here is a simple design mock I also created to illustrate the future extension of this service. Figma Link

1. Currently form limitations: formik + yup

   Using formik + yup is an simple and easy way for a fixed form validation. However, when it comes to the dynamic range of potential game settings, that means we then need to create/predefine different kinds of yup schema. That means the service right now is not yet flexible enough to generate and validation automatically.

   The change I would do is to enrich the json schema with all the conditions then use/create a JSON schema form could do both dynamic rendering as well as validation at once. e.g. react-jsonschema-form

   Right now, I worte a set of utils functions to iterate through the parameter schema and render the form according, but YUP is validation is still hardcoded.
   

2. formik vs react-hook-form

   formik is good and have a big community base, but in terms of performance, react-hook-form may be a better option, comparison, react-hook-form
   

3. limited implementation Since this is a quick assignment, due to time constraint, I didn't start the project based on the vision, more on the actual requirements. so there are some UI elments that are currently not implemented or could be improved, such as the editor, json schema utils(to support more complex use cases).

the api modules could ease the work when adding a new endpoint with minimum duplicated code

it defines different routes. Currently only has the main feature which is the parameter. More could be added to support consuming the parameter templates, such as in a game config editor

it contains all the redux/sagas where it handles all the async logic, ask all the CRUD operations

it uses the redux/toolkit and the duck pattern, reduced a lot of boilerplate from the old way

it is used to compute derived data

it contains all the components used in this app

__styled __: contains all the related styled component for a given component

__test __: test cases for a given component

About container and presentational components, in general, the rule of thumb is that i use index.js file to serve as the container for a given component, and all the remaining files under the same folder are presentational components

The parameter form is rendered based on the parameter schema. Currently due to the time constraint, only support basic schema (one level object based) with limited fields.

Supported Schema format:

{
      "id": "XXX",
      "title": "XXX",
      "description": "XXX",
      "type": "object",
      "properties": {
        "XXX": {
          "type": "string",
          "enum": [
            "easy",
            "hard"
          ]
        },
        "XX": {
          "type": "number"
        }
      }
    }

Supported form fields:

• Text,Number ===> input
• Text/Number with enum ===> dropdown
• boolean ===> checkbox