▓▓▓▓▓ ▓▓▓▓▓ ▓▓▓▓▓
▓▓▓▓▓ ▓▓▓▓▓ ▓▓▓▓▓
▓▓▓▓▓ ▓▓▓▓▓ ▓▓▓▓▓
▓▓▓▓▓ ▓▓▓▓▓ ▓▓▓▓▓
▓▓▓▓▓ ▓▓▓▓▓ ▓▓▓▓▓
▓▓▓▓▓ ▓▓▓▓▓ ▓▓▓▓▓
▓▓▓▓▓ ▓▓▓▓▓
▓▓▓▓▓ ▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ W A Y F O R G E
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
this is my personal monorepo where i work on typescript projects, including apps and packages
there's especially really cool stuff here. have a read...
atom.io npm install atom.io
anvl/join npm install anvl
import { Join } from "anvl/join"
imagine in-memory join table—an incredibly useful primitive when managing almost any real data
const playersInRooms new Join<{ joinedAt: number }>({ relationType: "1:n" })
// create a new join table for one to many relationships
relationships can hold their own data
playersInRooms.add("player1", "room1", { joinedAt: Date.now() })
// add a player to a room, with some data
supports serialization with easy conversion to JSON
const json = playersInRooms.toJSON()
check out the test suite to see how it's used
mostly done, but may need an API change since order matters.
cardsInDecks.add(cardId, deckId)
// not the same as
cardsInDecks.add(deckId, cardId)
// this SUCKS. need a more explicit API to express which id is which
maybe
const cardsInDecks = new Join({
relationType: "1:n"
}).from(`deckId`).to(`cardId`)
cardsInDecks.add({ deck, card })
This should provides check- and run-time type safety that avoids the problems above, at a slight tax to performance.