Skip to content

Latest commit

 

History

History
145 lines (105 loc) · 16.6 KB

NOTES.md

File metadata and controls

145 lines (105 loc) · 16.6 KB

Notes

Server

  • Using babel to execute typescript

  • When using extends in .eslintrc, the ordering is important. Latter rules overwrite former rules.

  • Using plugin:@typescript-eslint/recommended handled the issues of "not using interfaces" even though we were.

  • ESLint with Typescript imports

    • After a series of annoying Googles and searches for how to resolve "eslint import issues with typescript", we finally found .eslintrc configuration that worked. There may be extraneous typescript configurations. It's hard to tell because some configurations are needed for basic typescript linting. But at this point, we'll keep everything that's present. The import/extension rules and the import/resolver settings are definitely required. The others may just be related to proper typescript linting.
  • Creating "extensible" enums types

    • This is really just a way to keep type safety and "extensibility" for "enums" in JS without trying to go too C#/type crazy. Makes perfect sense.
    • You should beware of the enum conflicts example that andy-ms gives. However, currently, there isn't likely to be an issue where, for instance, A "Red Card" in Uno would be mistaken for a "Red Card" in Codenames. This is analogous to GoodMusic.RockAndRoll being mistaken for BadMusic.Rap in andy's example, since both of them evaluate to 0. But we aren't doing things like switch case scenarios at the moment. And our decks will likely be isolated during gameplay anyway. If the decks are brought together, the cards may still be of "the same type" anyway so it still may not matter. In any case, for now things appear to be safe. But we should consider these potential problems in the future.
    • Also be aware that this is probably one of the few areas that is "more TS than JS" as a warning. We want to be as much JS as possible. But this is only a slight deviation that really just focuses on expressing types, which are already a part of TS anyway.
  • eslint doesn't understand exporting types. It thinks you're exporting undefined. Nonetheless, the code still compiles. It seems eslint has a bug.

  • For export * as namespace from module, you'll need the babel plugin, which we have installed. Notice that this was a proposal that has been merged...but ES2020 is not out yet... See this tc39 proposal

  • For some reason, Nullish Coalescing and Optional Chaining are already in the babel preset that we're using. (It should be in ES2020 anyway.) We'll just take advantage of this.

    • Optional chaining looks more powerful in JS than you'd think. It's not just some simple C# syntax. It goes even further, like being able to use obj?.[key] (which makes for stuff like asking for dynamic properties).
  • Shuffling arrays in JS. This uses the Fisher-Yates algorithm, which is worth getting acquainted with...especially since it's simple.

  • Reservoir Sampling is a way to sample k items from a population of size n without replacement. We used the "optimal" algorithm (assuming it's truly optimal), though we had to properly interpret the algorithm for a 0-indexed array.

  • Initializing and Array with number 1-N (or 0 to N-1).

  • Common convention for functions in JavaScript like forEach is to name unused variables as _. For instance, array.forEach((_, index => ...)). If multiple unused variables are involved, then the common convention is to precede the variable name with an underscore (eg. _item instead of just _).

  • It seems adding TypeScript can screw up some of the normal intellisense. For instance, in our React Retro project (at least currently), we didn't have to install any explicit types for express. But now (likley because we have TypeScript and a TS config), we have to specify the express types by installing them. Similar things will probably need to happen for webpack if you want good typing.

    • Types are very important when working with TypeScript. It can impact whether or not TypeScript even knows which overload you're using (and allows you to compile that overload). This makes us have to do some work with process.env.PORT.
  • Quick Simple Implementation for Unique ID's

  • Warning about declarations in JavaScript switch/case. Use blocks!

  • TypeScript now supports private fields in JavaScript.

  • TC39 Private fields. Note that private fields are different from private methods. It doesn't seem like TypeScript supports those yet.

    • If you use these, you'll need to update Babel, though. (At least until the new stuff gets merged.)
  • Thoughts on ordering parts of a class. Note that some people prefer grouping public, private, protected methods, etc. But that may not always be helpful (if it's helpful at all.)

  • Partial can be used to make all the properties of an interface optional.

  • JSDocs will be worth understanding at some point. We started implementing some very lightly in Codenames.ts.

  • String enums are not so easy in TypeScript. Is it worth converting to numbers in certain circumstances in order to centralize things and avoid some "duplication"? Perhaps not... That might only work in certain circumstances...like with colors and numbers. It's hard to say.

  • Typescript: Defining an array of multiple types.

Quick Testing Server

  • Deck
    • A quick way to test that your deck is working properly is simply to generate a new deck. Then, immediately shuffle it, and log it in the console. You'll find the size of the deck, as well as the array of cards particularly helpful to look at.
  • Codenames Game
    • Testing a Codenames game may require a few runarounds. The simple way to do it is to use the readline built-in npm package. You can create an interface with the I/O streams using the createInterface method. Then, you can listen for events on the returned object. Use rl.on("line", function(input)). You can use it to force in your own cheaty actions as a player outside of the existing game. It should be quick enough, and you should easily be able to test win conditions. To observe other things like current player, you'll want to observe the gameState.
  • Remember that ideally, we'd want real, robust tests. At least right now, card games can be treated like a Redux Reducer to some extent.

Web

Web Sockets and Server-Sent Events

Extra

TypeScript

Vue Quirks