Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Pass tab object to tab-panel child function #5476
Add a second argument to pass the Tab Title to the Tab Panel child function for situations where tab title may need to be highlighted further to indicate users which Tab they are on.
How Has This Been Tested?
I tested the initial change with a proof of concept implementation using the Tab Title, then I updated the Tab Panel tests to account for the change which all passed.
Screenshots (jpeg or gifs if applicable):
Types of changes
This change adds an additional feature just by passing an additional argument to the function which is already required to be present. No breaking changes should occur, all code using the current code should continue to work fine
Would it be simpler to just pass the entire
selectedTab object, and the user could pick which properties they want to use? Particularly if they're already familiar with the object signature from the
tabs array, it seems like this would be simpler to use than predicting the order of the arguments.
I'd personally be okay with it being a breaking change. Not likely to have seen much usage outside Gutenberg. To me, seems like we should have passed the whole object to begin with.
Are you able to resolve the currently failing tests? Let me know if you need help.
Thanks for the updates @milesdelliott . Since April, my openness to breaking changes has shifted some, and I'm starting to question what we might be able to do to avoid breakage here. I still like the proposal as far as the desired interface (passing object as the argument), but wonder if there's a path for deprecation here.
One thought I have is deprecating with a global warning message (example), keeping the argument value as a string for backwards-compatibility, but assigning properties into it so that a transition option exists.
const tab = new String( 'Tab name' ); tab.title = 'Tab name';
It's very hacky, and we'd want to verify that using the constructed string this way works as we expect it to for existing usage. But I'd feel more comfortable about the transition if we could offer some compatibility.
I'm all for avoiding breaking changes. I've updated the code to assign all the original properties of the tab object to a new String object with a value being the tab name.
I tested it with a dummy component and it looks like it works well being used as the string or accessing the properties.
My only concern would be the increased complexity and making it harder for other developers to understand, but I don't think it's too bad and it is a nice transition step to be completely taken out in the future.
I kept the version for deprecation at 4.0.0, but let me know if that should be pushed out further.
With 3.9.0 already in release candidate stage, we should consider all pending merges to be scheduled for 4.0.0, meaning 2 versions out would put it at 4.2.0 removal.
Definitely not great if it were a solution intended to be used long-term
referenced this pull request
Sep 18, 2018
Verified the deprecation approach in an isolated environment:
An open question as to whether this is a component we should continue to offer if it's not used internally, though it seems generally useful.
Tests were failing, though it appeared to be an intermittent one. Hoping it works this time after a build restart.
You might look to do something like here to avoid the console log triggering the failure: