setTabCloseEventListener fails if tab does not use close button.

[Rick Peaugh]

Our application has one permanent tab, the home tab if you will, and it does not require the close button on it. You can see the error in the console when the page opens. Simply leave out the line in your html that says:

<div class="chrome-tab-close"></div>

I resolved this as follows:

setTabCloseEventListener(tabEl) {
    if (tabEl.querySelector('.chrome-tab-close') != null) {
        tabEl.querySelector('.chrome-tab-close').addEventListener('click', _ => this.removeTab(tabEl))
    }
}

[Adam Schwartz]

Thanks @rpeaugh! This can also be solved without changing the library JS by using some additional CSS:

.chrome-tab-close {
  display: none !important
}

One advantage of this approach is it might allow you to easily toggle the closeability of a tab. This could be useful for #64 for example.

[Rick Peaugh]

Hey Adam,

Thanks for the response. The CSS could be useful as you described.

I was thinking about the pinned tabs issue when I made that simple code change. With the code change, one can leave off the draggable and close options and the tab is "essentially" pinned. The one remaining issue is that, although it cannot be dragged, a draggable tab can be dragged over it, forcing it to move. This is a minor issue, but if draggabilly were updated to not be draggable over icons that are not draggable, then the first tab would remain pinned in that location. I would think that most developers, such as myself, are wanting to pin a Home/Welcome tab as the first tab. And as long as all pinned tabs were adjacent, and starting from the first tab, then they would all remain in those positions. On a side note, the code change eliminates the error that occurs when you leave off the chrome-tab-close class. Which, in my opinion, makes the code more friendly.

Now, if one were trying to create some tabs such as:
[pinned] [draggable] [draggable] [pinned] [draggable] [draggable]
That would definitely be an issue. Keeping that fourth tab in the fourth position, I cannot fathom a reason someone would want to do this. Though I suppose you would have to make the draggable tabs only draggable between the pinned tabs. Otherwise, the pinned tab would shift when a draggable tab was moved across it and it would no longer be in the fourth position.

[Adam Schwartz]

Thanks @rpeaugh for this thoughtful context.

I could imagine an app that doesn’t need the concept of pinning tabs, but still wants to hide the close button on all or some tabs. Someone might simply want to hide the close buttons for aesthetic reasons while still supporting tab closing via a keyboard shortcut, for example.

So we’ll want to support the Google Chrome notion of pinned tabs (#64) while also keeping the library flexible to support the arbitrary hiding of a close button as needed by an app developer. This shouldn’t be too complicated to achieve but it may require a destructive version bump and/or motivate the need for more substantial documentation. All of which is possible, but just work I can’t commit to at the moment. Always open to a PR ;)