User profile friends do not show properly

[kachnitel]

Only an empty circle without a name is shown in the Friends list of an user's public profile

see ridetime-server#22

Update lists to return thumbnails for friends. Show list items using thumbnails, and when the list is displayed, run a 'populate' on background for IDs shown

[kachnitel]

De-dupe lists:

• RidersList.js: (is the original user list and...) nearly a duplicate of FriendList.js.
• FriendList.js: the horizontal one w/ only pic & name used in Profile
• UsersList.js: vertical list used in FriendListScreen, AddFriend etc, alternating clr)

Referencing options

Use IDs only

• Deprecate getThumbnail() at API, use Store.populate() on list of IDs
• Easiest solution, but list details only start loading once the list is mounted causing a delay

Use "thumbnail"

• Each list item is a "sample" of an object being referenced (ie { id, name, picture } with minimal parameters necessary
• Such item should be stored in store._collection with a "thumbnail=true" flag
• List item can then show preview immediately store.getPreview (sync, only local lookup) while the List is loading details in bg, making transition to list instant
• store.getSync would throw an error if existing entity is a thumbnail. store.get/store.getEntity must treat thumbnail as non-existing item
• Only useful for User?

Add thumbnail to store

1) updateFriends/addFriend creates the entity with info from thumbnail 2) ID of created entity is added to friends list (or whichever entity) 3) List component then uses [ids] and each list item uses user.getThumbnail() (as getSync would fail, get would be inefficient and all details would instead load in background)

Issues

• If said relationship is between different Entity types (User & Event for membership), UserStore has no access to EventStore to populate thumbnail details

Use full items

• Can be implemented in JSON.API style

Issues

• Population of a different entity type / store (same as using thumbnails in store)
• Creates a recursion issue if objects are supplied within the entity itself (ie when friends is a list of User objects, then each has its own friends
  • GET entities (list) may return a list of objects with IDs for relationship (current implementation as of API 0.2.1
  • GET entities/{id} (detail) may then include related entities

{
  "result": { ... },
  "relatedEntities": {
    "users": [],
    "events": []
  }
}

[kachnitel]

WIP on receiving related entities (JSON:API inspired style) in stores in 4eabecbc972a558a0046da952ed0f932162c3edc

The next dilemma will be:

Distribute received entities to other stores (user receives locations, events in detail)

• Should "primary" stores reference each other to be able to populate other type entities?

• Should there be a store "Above" primary stores (not ApplicationStore) that would spread the goods, allowing for separation of stores

• EntityManager - Sort of between both worlds

  • EventStore is currently receiving userStore (from singleton) prop in constructor
  • which would be instead imported in EntityManager along with other 2 collection store singletons and an EntityManager instance would be created, passed into each store's constructor?
  • Causes circular reference when same store is available within itself through the Manager
  • Each store would have EntityManager prop with all 3 primary stores, which would then be used to handle data with matching name (event => EventStore etc..)
  • In which case populateRelated could simply be moved into the mgr and stay clear of the BaseCollectionStore or individual stores, use the "key" to distinguish destination
  • EventStore would of course switch to EntityManager from using UserStore directly

[kachnitel]

API 0.3.0 now sends relatedEntities to populate the store, list renders correctly. Also de-duped identical list components (FriendsList and RidersList)