Reference_blocks for cards

[jkomoros]

Originally captured in #399

these reference blocks shouldn't be literal items in the HTML, but should be extra metadata on the card:

{
  //...
  reference_blocks: {
    'similar/SELF/limit/10/': 'Similar',
    'children': 'Children',
    'query/foo/': '',
  }
  //...
}

Where the text SELF is matched and replaced with the card's own ID. The values in the dict are the display names for that collection, '' is legal and means 'don't describe what they are'. There are various aliases predefined, e.g. children expands to children/SELF/ and similar expands to similar/SELF/limit/10. If the display name text is empty, and the alias has pre-defined display name, it will use that instead.

And then the card's main content gets flex 1, and the reference blocks get the remaining space, scrolling if necessary to fit.

And then a card like a concept card would be primarily one with empty content and a predefined reference block of parents/SELF.

... We'd also need ways to have filters for specific types of references, as opposed to all of them. Maybe references/CARDID/DIRECTION/TYPE/LIMIT, where direction can be {inbound|outbound|both}, type can be any valid reference-type (or multiple joined with +, and an argument that starts with - means "the inverse of the set that follows", and limit is the number of ply, where 0 is unlimited.

And then conceptually, the things that show up in card-info are like reference-blocks that are defined by the application to show up irrespective of what the card itself says.

Card types can add reference blocks that show up on every card of that type (deduped against whatever the literal card defines).

There should be some way in the configuration of a reference block to define if it hides when the collection is empty or not.

TODO work through whether reference blocks work well for citations use case (#202)

[jkomoros]

• [x] cardBFS learns how to handle a specific reference type optionally
• [x] Create a {direct-|}references{|-inbound|-outbound}/CARDID/TYPE/PLY/ type of filter
• [x] Create a direct-references which is like references but doesn't take a limit argument
• [x] Bug: twoWay connections where the latter item has no matching items skips key card
• [x] Allow references/ filter to have unions of reference-types
• [x] Allow references/ filter to have inverted list of reference types
• [x] reference (and all of the link filters like descendants) should accept a ply of 0 to mean "unlimited"
• [x] Document ply = 0, and unions and inverted reference types in help
• [x] Document new configurable filters in help
• [x] Create a referenceBlocksForCard(card) which returns the collectionDescription --> title for the card. It starts off with just being based on card_type
• [x] Refactor card info panels to be expressed as secondary reference blocks
• [x] Refactor out the cards that link here in info panel (need bolding of cards that don't yet link here)
• [x] Refactor out the similar cards in info panel (needs to use editing card in similar cards . have a 'active-card' card in the cards collection? one downside is that that would always subtly tweak the idfs (by doubling the active card)).
• [x] Figure out how much slower the info panel is now that it uses collections for every reference block.
• [x] Make sure that the things that show up in panel are editing/active card (including similar cards)
• [x] Collection instead of taking a list of arguments, gets an argumentsCollection, which it stores directly, so it can pass it into blocksForCard.
• [x] Pass expandedReferenceBlocks to all occurances of card-renderer where it's useful
• [ ] Show a 'loading' for cards that reference this concept when applicable
• [x] Collection gets a expandedReferenceBlocksForCard(cardID) which on demand generates the expanded reference block, making sure that everything can be memoized (note this requires disentangling a circular import) (maybe just have a getter for the constructorArguments?)
• [x] base card renders the result of referenceBlocksForCard into the bottom of the card
• [x] Figure out some way for screenshotting to handle cards with reference blocks correctly (for now, just render a blank block with a message. But in the future, perhaps have the machinery to do queries be server side?)
• [x] SELF is treated specially in collection description in configuration (make sure it's a reserved name)
• [x] Create expansions in reference block definitions e.g. children, including display title if it exists
• [ ] Some card types render a see also reference
• [x] Cards grow a reference_blocks that overrides anything for card type in referenceBlocksForCard
• [x] Make sure that font autosizing works with this

[jkomoros]

Ideally this whole system is rationalized with card-info-panel, too, where it just renders them differently. But notionally there's the web app's list of referenceBlocksForCard() and the card type's and the card's.

That implies there does need to be a way to handle "Show if empty". For the collection description, it should be a map of description --> [displayName, showOnEmpty]. A string expands to [string, false], a falsey-value expands to ['', false]

[jkomoros]

Instead of having the direction be a configuration, just have references-inbound, references-outbound, references, and direct-* variations of each.

[jkomoros]

For replacing the Similar cards in card-info panel, the collection description will be something like everything/similar/self/exclude/direct-references/self/SUBSTANATIVE_REFERENCE_TYPES/limit/10.

The main problem is that the key card should be the editing or active card, not just the literal value of cards.

There are a few bad options:

1) Make it so that configurableFilters are passed card, cards, editingCard. This is annoying because we have to pass around editingCard in basically ALL filter machinery. That's not the end of the world, but it is weird that it's passed around for just that one use case. 2) Make it so that the cards collection passed to CollectionDescription.Cards actually munges out the active card and replaces it with the editing card if it's non-null. The downside of this is that cards will change each and every time the editing card changes, requiring recalculating fingerprints, etc. 3) Add in a special active-card card ID into the cards array, which has behavior similar to the second option. There's still the same downsides of the cards array will keep changing as the editing card is being changed.

[jkomoros]

Base card rendering primary reference blocks gets a bit weird, because before the only thing necessary to render a card was to pass the card itself, but now to render a card requires not just passing the card itself but also the reference blocks, which implicitly rely on potentially arbitrary queries across the entire database. 😬

That's kind of weird in a tactical way that it breaks card rendering optimizations for the twitter bot, but it's also a larger smell...

getExpandedPrimaryReferenceBlocksForCard relies on state, which is constantly changing. Ideally it would rely directly on the constructor arguments. Maybe it can do its own memoizing based on whether the constructor arguments have changed.

[jkomoros]

All sub issues moved to other issues or done.