733664 - Drawer: stateless entry into any stack or stackplaces view

Status: RESOLVED INVALID

(Pancake Graveyard :: Front-end, defect)

Description

[Gordon Brander :gordonb]

What I expect: when I click a stack result, it shouldn't open the drawer, but it should update it's state so that when I open it, it reflects the current state of the app.

What happens: not that.

We need an easy way to change drawer state from outside of drawer. There is currently no event handler or route in drawer.app that handles this use case.
 The obvious API for this is the URL router.

Drawer is almost READ-only. That is, it only shows what the API or TOP 'navigate' events hand back. It never writes anything except WARPS.

Proposed solution:

* I believe drawer should handle POSTing and PUTing to Lattice
* Events should come in the form of stack[:stack_id], place[:place_id, :stack_id]
* If the controller finds that the Stack or Place requested is missing, it issues a fetch({diff:true}), so only new places/stacks are added, and previous ones are left alone.

This allows us to get rid of state and do everything through the URL router by passing IDs.

It is likely that this would also fix #730132, which I believe to be a statefulness bug.

Comment 1

[Sam Foster [:sfoster] (he/him)]

I agree in principle with this. I think we should hold off on implementing until we have a number of bugs that justify it. AFAICT right now we have most of these state-related bugs cornered and fixed.

Comment 2

[Gordon Brander :gordonb]

Actually, perhaps MAIN should handle POSTing and PUTing new stacks.

If we don't want to make an additional HTTP request, we should send messages between apps in the same JSON format they are sent from the server. This way, the drawer doesn't need to know the difference between a true HTTP response, and event data. If we can have the server be our source of truth, or at least a proxy for the server (like an event that passes the same data format), at least everythig will pipe through the same logic. We don't have robust enough state syncing to do statefullness, and it's difficult with just passing messages.

---

We can also get rid of stack:change and make everything a place:change event.

Places always belong to a stack. A place may belong to multiple stacks, but to log it we have to disambiguate it. This means a place:change requires a stack_id and a place_id.

A stack:change uses the active place_id as an implied place_id for the stack. It is essentially the same action as a place:change.

Comment 3

[Gordon Brander :gordonb]

Play-by-play of state bugs I am having with current top-stacks branch:

Wiped data: starting over.

* Search for "Sufjan Stevens"
* Clicked link, stack added
* Drawer navigated to.
* Correct place shown as active.
* Clicked link in page -> Place added below page
* Clicked back
! Clicked link in page -> place added below page. Getting inserted below correct place. Place appears smaller than others. Getting inserted in to the `<li>` of the parent page. That is not right. It should get inserted beneath.
! Clicked off of new page. Douple selection (probably because of where it is being inserted)
* Clicking between items issues warp.

Repeated above with "The Verge":
! Clicked off of new page. No double-selection.
! Clicking below wrongly-inserted stack results in double-selection.

Clicking out of stack and into "Sufjan" stack
* "Sufjan" Page is highlighted
* Click "BQE" page
! Uh-oh "All Delighted People" page has disappeared and has been replaced by a duplicate "BQE" page
! Click out of Sufjan stack. Stack title is not updated -- still says "Sufjan".
! Click back in to stack - double-selection of "BQE" page, but Sufjan Page is still displayed.

* Click in to "Verge" stack. Rendering has been fixed.
! Click out of "Verge" stack. "Sufjan" stack still displayed as active.

Refresh.

* Click "Sufjan" stack.
* "All Delighted People" page is back. The "BQE" page is highlighted and loaded.
* Click "All Delighted People" page.
* Click out of stack.
* Page title is reflected in stack.
* Click "The Verge" stack. It says that "The Changing Face of Ecommerce" is active.
* Stack displayed. "The Changing Face of Ecommerce" is highlighted as active.
* Click page "Garage Band for iPad"
* Click out of stack
* Updated page title is displayed in stack.
! Page titles appear to be doubled in stack list view for all stacks.
! "Sufjan" stack is still shown as active

Refresh.

* Click on "The Verge" stack.
! The "Changing Face of Ecommerce" is loaded and shown as active. Should be "Garage Band for iPad".
* Click OUT of stack into stack list.
* Click link "Jamie Keen"
* Stack title is updated in stack list
! Click into stack places view. "Changing Face of Ecommerce" is loaded and shown as active. Should be "Jamie Keen".
! Jamie Keen is added to the bottom of list. Should be directly below "Changing Face of Ecommerce".

Comment 4

[Sam Foster [:sfoster] (he/him)]

I tracked down a couple of bugs. 
* We didn't capture the new place_id when the stack/link request came back, so the 'current' placeid which was used as the 'insert_after_place' was wrong. That's fixed in https://bitbucket.org/mozillapancake/pancake/changeset/53735fa396df

* The sub-view insertion was getting tangled up because I had the data-id attribute on the wrong element. https://bitbucket.org/mozillapancake/pancake/changeset/a718e09f89f4 fixes that

I've not seen the doubled-up places since these fixes.

Comment 5

[Gordon Brander :gordonb]

Drawer app needs to keep the currently active stack_id in memory for new places to be appended to the correct stack. Drawer should have addressable read-only states via the router, and have minimal state, but can not be stateless completely.

Drawer should keep track of:

* Currently active stack_id
* StackCollection

StackModel should keep track of:

* Currently active place_id
* Places Collection

PlaceCollection should keep track of:

* Pointer to parent StackModel instance

SiteModel should keep track of:

* stack_id

Basically, the only duplicated state information should be IDs or pointers.