Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The proposed update
success
anderror
to get rid of redundant constant declarationnormalizeOptions
, implementing strict type checking forpayload
object. The methodtypeof payload === 'object'
, used before, fails to detect the type clearly, if passed payload inherits Object prototype being de facto non classic Object. This can lead to possible uncaught runime errors and at least results in displaying empty notification. For example,notyf.error(Array.of('They see me rolling'))
,notyf.error(new String('They see me rolling'))
ornotyf.success(null)
, since the checktypeof Array.of('They see me rolling')
,typeof new String('They see me rolling')
andtypeof null
will identify these Array, String and Null instances asobject
normalizeOptions
, correcting the logic of workflow (although it may be subject for discussion) by swapping the order ofpayload
andoptions
during the merge. (options = { ...options, ...payload }
=>options = { ...payload, ...options }
). The point is to assure the notification, produced by options normalization subroutine, is exactly of type passed in 1st argument tonormalizeOptions(type, payload)
function regardless of properties of payload object. The logic, used before swapping, could result in curious things like invocation ofnotyf.error({ type : 'success', message : 'They see me rolling' })
, which despite the name produces the notification of typesuccess
open
, covering the original code with additional check to assure the argument passed tonotyf.open(options)
function is of expected classic Object type and thisoption
object contains propertymessage
with value of type String. The point is to avoid arrival of empty notifications if for some reason the options hasn't been combined properly. This improvement has an impact only on accidental failures and one still is able to push an empty notification likenotyf.error('')
ornotyf.open({ type : 'success', message : '' })
, declaring message as empty string