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
There is one reason why I consider deep merging better. Before version 9.0.0 there were separate options for confirmButtonClass, cancelButtonClass etc. If you take the code I gave in the description and adapt it to an older version of swal, you will get this:
Here the test.fire call will override confirm button class to 'orange', but leave cancel button class intact. In my opinion, this discrepancy in behavior between <9.0.0 and 9.0.0 is an unnecessary backward incompatible change, only caused by the fact that 9.0.0 uses shallow merging strategy for aggregate options it introduces (customClasses, hideClass and maybe some others). Someone who needs to upgrade swal <9.0.0 to ≥9.0.0 is likely to change confirmButtonClass, cancelButtonClass etc. into customClasses: { ... } mechanically and only then discover that merging doesn't work as before.
It is possible to use a custom function instead of swal.mixin as you suggest, but deep merging, among the three options you listed, seems the most intuitive to me because it matches the behavior of swal <9.0.0. So I would prefer to have it out of the box. Although, it may already be too late to make such changes in swal.mixin...
Anyway, I am of course not insisting. I just wanted to hear your thoughts and motivation.
Before I forget, I would also like to suggest documenting the current shallow merging strategy on https://sweetalert2.github.io/. Docs for swal.mixin are barely existent:
Hi @zenflow , thanks for your reply!
There is one reason why I consider deep merging better. Before version 9.0.0 there were separate options for
confirmButtonClass
,cancelButtonClass
etc. If you take the code I gave in the description and adapt it to an older version of swal, you will get this:Here the
test.fire
call will override confirm button class to 'orange', but leave cancel button class intact. In my opinion, this discrepancy in behavior between <9.0.0 and 9.0.0 is an unnecessary backward incompatible change, only caused by the fact that 9.0.0 uses shallow merging strategy for aggregate options it introduces (customClasses
,hideClass
and maybe some others). Someone who needs to upgrade swal <9.0.0 to ≥9.0.0 is likely to changeconfirmButtonClass
,cancelButtonClass
etc. intocustomClasses: { ... }
mechanically and only then discover that merging doesn't work as before.It is possible to use a custom function instead of
swal.mixin
as you suggest, but deep merging, among the three options you listed, seems the most intuitive to me because it matches the behavior of swal <9.0.0. So I would prefer to have it out of the box. Although, it may already be too late to make such changes inswal.mixin
...Anyway, I am of course not insisting. I just wanted to hear your thoughts and motivation.
Before I forget, I would also like to suggest documenting the current shallow merging strategy on https://sweetalert2.github.io/. Docs for
swal.mixin
are barely existent:Originally posted by @earshinov in sweetalert2/sweetalert2#2039 (comment)
The text was updated successfully, but these errors were encountered: