Introduce OperationStore to add operations on-the-fly

[marcoroth]

Type of PR

Feature

Description

This PR introduces a OperationStore to add operations on-the-fly.

This also removes the playSound operation. The operation has been extracted to: https://github.com/cableready/audio_operations

With that a developer can add custom operations from packages to their app.

// app/javascript/packs/application.js

import CableReady from 'cable_ready'
import AudioOperations from '@cable_ready/audio_operations'

CableReady.addOperations(AudioOperations)

Deprecate CableReady.DOMOperations

As CableReady is more than just "DOM operations" we should also change the name. This is still supported but shows a deprecation warning:

CableReady.DOMOperations.jazzHands = (operation, name) => {
 console.log('Jazz hands!', operation)
}

Instead you can now use this:

CableReady.operations.jazzHands = (operation, name) => {
 console.log('Jazz hands!', operation)
}

As a side effect it now also allows more ways of defining custom operations:

CableReady.addOperations({
 jazzHands: (operation, name) => {
   console.log('Jazz hands!', operation)
 },
 jazz: (operation, name) => {
   console.log('Jazz!', operation)
 }
})

CableReady.addOperation('jazzHands', (operation, name) => {
 console.log('Jazz hands!', operation)
})

Why should this be added

Developers can build npm packages with pre-build CableReady operations and just add them with a simple function call to CableReady.

Checklist

• My code follows the style guidelines of this project
• Checks (StandardRB & Prettier-Standard) are passing
• This is not a documentation update

[leastbad]

This is a masterclass-level refactoring job. Bravo.

[julianrubisch]

Would it make sense to implement OperationStore in JS class notation (for better readability)?

[hopsoft]

Very nice! Great job.

[hopsoft]

Would it make sense to implement OperationStore in JS class notation (for better readability)?

I'm ok to punt on this unless y'all feel we should do it now vs later.