eriwang / aen_tabletop_tooling Goto Github PK

Currently a bunch of smaller components try to get the status of the currently authenticated user - probably means there's a bunch of duplicated logic that can be combined into one user state at the top of the app.

Fields such as currentHp and initiative live on the character itself, are modified in place, and should be persisted if the character changes due to a profile change. It's confusing and unclear which fields fall into this category, we should somehow separate these out (possible examples: adding a nonCalculated key in the data structure, or having a NonCalculatedCharacterData table)

We should run some check to validate all our existing data matches our schemas in code every so often. It's possible to schedule functions (we seem to get 3 scheduled functions free?), but that's not necessarily the path we need to take.

If not run recently, Cloud Function instances spin down and take a while to spin back up. We should add a warm_endpoint option to every Cloud Function and call that on webpage load to avoid the latency from spinning back up.

The following should have Firestore implementations ("schema" TBD):

• Unit
• Profile
• Weapon
• Abilities

There's a little bit of code to build a Character class from a Profile and Unit class, but there's some assumptions that made on shape of data (e.g. that profiles contain all armor details) that don't match with the real state of the world. It's likely easier to rip that building functionality out and put it into a cloud function. We should probably only need the actual dependencies of a character when building it, after it's built everything should be contained in the character itself (especially because all that info gets rendered to the UI as well).

Would be nice to have isAttack, hasTarget, hasMultipleTargets, hasUnevenDistribution, etc... living on the abilities, flags that the front and back end both understand to control calculations and how the UI gets rendered.

https://github.com/react-grid-layout/react-grid-layout

This would allow for a customizable character sheet, for example.

We should be able to track nearly all character state in a "Character" table which is derived off of the "Profile" and "Unit" tables (possibly among other tables in the future). We should implement this table and set up database triggers to modify the table when upstream tables are changed.

So that the UI doesn't just render "INTERNAL" when calling callable cloud functions

The essence of a data converter so far has always been "read Firestore, check for required fields, and throw if they aren't there", or "write a dictionary-like structure to dictionaries". We should be able to generalize these better and reduce the amount of code we write there.

Picking a new character in the CharacterSelector component is causing the UI to freeze for a second or so - need to figure out why and how to fix this.

Example: https://jackywu.ca/2021/2021-01-02/

It's currently difficult to manage dependencies in this repo, yarn calls are all over the place and confusing to use. We should leverage yarn workspaces, and possibly use the setup in the above link and use webpack to play nice with Firebase Cloud Functions' requirement of a package.json.

User flow:

1. User clicks calculate attack
2. Result prints out "Attack hit, cost 4 FP and did 9 HP damage"
   • The FP and HP fields would be editable
3. User clicks "Apply values" or "Publish" (or similar) button to actually modify those items in the database

On the Firestore side, it's clearer to store strings as opposed to numbers for fields like "weapon attribute" or "damage type". Using string enums simplifies the conversion between the db and the code.

It would be interesting to see a public "game log" of actions taken (e.g. "Char 1 attacked Char 2 with Ability for 10 damage), instead of just the "final state" (e.g. in the previous example, "Char 2 has 60 HP remaining). This would likely require a new Firestore "game log" table that the front end would need to listen to.