You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know this was part of the cleanup / make it easier some time ago (v1 I think), but why not work (optionally) with an objects instead of plain array structure? It would make customization (like in #127, #79, #72, #58) much easier. Something like this:
where TabItem would be a new class of this package, holding the fields. To keep it backward compatible, you could also allow to use the "old" syntax with array key-values.
Why? The benefit of this would be, that you can extend and chain methods to each single tab. Please let me show you some examples:
Or you could even implement a couple of other features, like icons:
Tab::make("Tabs", [
TabItem::make("My title (4711)", [
// ...Fields...
])->icon("<svg....>"),
])
But this isn't necessary to make it as a seperate method, if you don't want it. Just make the "title" html able and since we can now set the name seperatly, we could do it like so:
Tab::make("Tabs", [
TabItem::make("<svg ...> My title (4711)", [
// ...Fields...
])->name("my-title"),
])
Or even give the tab extra css classes, to have different colors for tabs, for example if you wanna make a tab red, because its a very important one or has some things to do on it:
I actually really love this idea. It would take a bit to implement and needless to say this will not be possible without actually adding some unit tests (which are also planned). I'll look into this.
I know this was part of the cleanup / make it easier some time ago (v1 I think), but why not work (optionally) with an objects instead of plain array structure? It would make customization (like in #127, #79, #72, #58) much easier. Something like this:
where
TabItem
would be a new class of this package, holding the fields. To keep it backward compatible, you could also allow to use the "old" syntax with array key-values.Why? The benefit of this would be, that you can extend and chain methods to each single tab. Please let me show you some examples:
#127 "How to customize a tab name in a URL?"
#79, #72 Icons
Or you could even implement a couple of other features, like icons:
But this isn't necessary to make it as a seperate method, if you don't want it. Just make the "title" html able and since we can now set the name seperatly, we could do it like so:
#58 Conditionally show tabs
Only show tabs, if a condition is met. For example with the help of a callback:
Style each tab separatly
Or even give the tab extra css classes, to have different colors for tabs, for example if you wanna make a tab red, because its a very important one or has some things to do on it:
And many more ...
... the nice thing is, that you should or could make the
TabItem
macroable, so that each user of the package could extend it, if needed, by themself.To keep it backward compatible
... you could allow also the "old" syntax and allow mixing:
The text was updated successfully, but these errors were encountered: