Hooks may behave not as expected

[johnd0e]

Here I'm going to list misc. unrelated weirdness.

1. Already described in #325 (should be addressed in #437)

[johnd0e]

2. On portal click renderPortalDetails is called thrice:
   • render cached data immediately
   • render response from server (onSuccess )
   • onSuccess also results in reparse entity -> portalDetailLoaded -> renderPortalDetails

One is needless (should be addressed in #437)

[johnd0e]

3. portalSelected may be called often
   • on explicit user action (another click on same portal). Pretty obvious case
   • on unobvious internal reasons, e.g.
     • explicit click causes portalSelected, then renderPortalDetails -> portalSelected again
   • it's called every 180 s, perhaps at the end of the render pass (renderPortalDetails)
   • etc.?

[le-jeu]

portalSelected is trigger by selectPortal on each renderPortalDetails call.

When renderPortalDetails is called directly by a user click (portal or link/selectPortalByLatLng commonly used by plugins)

• selectPortal is called
• if portal details is not fresh in cache, request details
  • on response:
    • call renderPortalDetails
    • call createPortalEntity by the portalDetailLoaded hook, ending with a renderPortalDetails call if the data has changed

Also, renderPortalDetails is called at the end of the render pass (move/zoom/idle refresh)

Reverse call tree of renderPortalDetails

• window.renderPortalDetails
  • processDeletedGameEntityGuids (unselect)
    • processTileData (never called ?)
    • processRenderQueue
  • endRenderPass (for selected)
    • processRenderQueue :warning: :one:
  • getPortalDetails response (for selected) :warning: :two:
    • window.renderPortalDetails :warning: :two:
  • createPortalEntity (for selected)
    • processGameEntities
      • processTileData (never called ?)
      • processRenderQueue :warning: :one:
      • hook mapDataEntityInject callback
    • createPlaceholderPortalEntity
      • createLinkEntity/createFieldEntity
        • processGameEntities...
    • hook portalDetailLoaded (for selected)
      • getPortalDetails response :warning: :two:
  • marker click
  • zoomToAndShowPortal
    • link in interface/plugins
  • selectPortalByLatLng
    • link in interface/plugins
  • link in interface/plugins
    • search
    • close portal details (unselect)
    • bookmarks, portals list...

[johnd0e]

Thoughts:

1. We should consider that all the code relies on that renderPortalDetails will make portal current. When portal in not on map yet - that can be deferred, with unexpected consequences - e.g. we click through several portals, but after a second we see that selection returned to some previous.
2. Anyway to avoid useless hook calls selectPortal should not be called unconditionally. I suppose somewhere (in renderPortalDetails or in selectPortal itself) should be some check if (guid !== selectedPortal) { ....
3. zoomToAndShowPortal/selectPortalByLatLng should be refactored anyway #93