add ability to over-ride tab onClick

[mixmix]

Type: Feature.

Problem: In Patchbat, the app tabs state is currently split over the history store and tabs. I'm trying to move to a more reactive architecture where action lead to changes in the history store, which lead to changes in the tabs. To do this nicely, I need to be able to take control of the tabs onClick.

Solution: add another opt to make it possible to over-ride the onClick

[mixmix]

@dominictarr I'll npm link this in and make sure it's working. If you don't have any input in a couple of days I'll merge this and publish (if I can), as this is only adding a feature, not modifying features.

I did change the signature of a method to take opts, but it's an internal function

[mixmix]

oh i just realised that onSelect and onClose are hooks, and this onClick is an override. probably need a different name at least, and docs

[dominictarr]

Is the goal to be able to have tabs that have forward/back history as well as having the ability to open new tabs? This is something I've been considering, but havn't gotten around to yet. Am wondering if the right solution might just be to just support that feature in hypertabs?

Hmm, or should a tab open a page-with-history, that then internally manages forward/back. It may want to wrap some UI elements such as a location bar (that persist between positions in history?)

[mixmix]

Zooming way out, the goal is to make Patchbay have a tab system which can handle almost all of the state about which tabs you've visited in which order in one place (consolidate state).
My first inclination was to pull as much state as possible into the patchbay history. This motivated me to want to remove hypertabs control of selected tab - I wanted to set my own onClick of a tab, which would then change the history store, which would then tell tabs what to open.

I think what you're suggesting sounds way cooler. 😎 Basically recreate the tab experience I have in firefox, so that :

• a tab is a window with a history - you can go forward and back
• you can open links as tabs in the background by ctrl clicking
• there's a 'tabs-visited' history which is mainly used to handle which tab to fall back to when the current tab is closed.

---

I just made some updates to this PR which are still good - they distinguish onClick as over-rides to onClicks, and Hooks as hooks which get called in addition to the things that were already being called. I weeded out a bunch of redundent hook-type calls

[mixmix]

p.s. I was having trouble working on the tabs thing in Patchbay. I wrote down all the cases you have to cover for state transitions here D: https://github.com/ssbc/patchbay/blob/better_goTo/docs/page-state.md

[mixmix]

mmm @dominictarr I need to draw up my tech tree. I'm really excited by this new idea, AND there are so many important things that could perhaps go ahead of this. Like it's more strategic for me to pair with new people to make awesome apps.
I wonder if this could be a casual no-pressure project I could do over a weekend instead.

[dominictarr]

Interesting. btw, I think it's worth discussing what common features a layout system needs.
%PiOtOwW0dZe9fH8dMSn1kbhj2bzyvvgCDWNhu+ZB0rw=.sha256

Given that we've a number of applications built that have different layout opinions I think we can see that there are different valid ways you might want to structure the overall application (tabs, patchwork's simpler few-main-pages + forward/back, minbay/patchfoo's inherit browser's tabs, etc). I think this is a very good candidate for a plugin api. Also, there will be many advantages to being able open views in a standard way.

So, I want to talk about: what is in common between any nav system, and what api should a page in that system have? If we can specify that, I think we will get a lot!