Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat: custom render function #2819

Merged
merged 2 commits into from
Jun 3, 2023
Merged

Feat: custom render function #2819

merged 2 commits into from
Jun 3, 2023

Conversation

katspaugh
Copy link
Owner

I've added a new option renderFunction: (peaks, ctx) => void which allows swapping out the default rendering function for a custom one.

Screenshot 2023-06-01 at 08 58 12

Resolves #2811

@cloudflare-pages
Copy link

cloudflare-pages bot commented Jun 1, 2023

Deploying with  Cloudflare Pages  Cloudflare Pages

Latest commit: 7fa4dab
Status: ✅  Deploy successful!
Preview URL: https://9d187782.wavesurfer-js.pages.dev
Branch Preview URL: https://custom-render.wavesurfer-js.pages.dev

View logs

const halfHeight = height / 2
// Custom rendering function
if (options.renderFunction) {
options.renderFunction(channelData, ctx)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing, exactly what i needed in #2815

Copy link

@euvl euvl Jun 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Random thoughtdrop:

Made me think that if might be beneficial to put everything from line 239 till the end of the method into some sort of defaultRenderFunctionFactory(name needs some work 😆 ), decoupled from the renderer module context.

As a sort of default rendering function factory to do something like:

...
renderFunction: defaultRenderFunctionFactory(barCustomizationOptions)
...

where defaultRenderFunctionFactory is:

const defaultRenderFunctionFactory = (channelData, context) =>  (options) => { ...render }

The reason i was thinking about it - i'm guessing a lot of custom rendering will be always "almost" the same, and having a very flexible "default" renderer will be beneficial; also will be easier to copy default and "change it" for lib users

Copy link
Owner Author

@katspaugh katspaugh Jun 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I follow.
We already expose a lot of options to customize the default rendering. If one wants something even more custom, they can write a custom function.

@katspaugh katspaugh merged commit aaf758f into beta Jun 3, 2023
3 checks passed
@katspaugh katspaugh deleted the custom-render branch June 3, 2023 06:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants