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: limit view fields exposed to render function #138

Merged
merged 6 commits into from
Jun 16, 2023
Merged

feat: limit view fields exposed to render function #138

merged 6 commits into from
Jun 16, 2023

Conversation

manzt
Copy link
Owner

@manzt manzt commented Jun 14, 2023

Description:

This PR addresses issue #137 by making changes to object exposed to user-provided render.

Previous:

class AnyView {
  async render() {
    // ...
    let cleanup = widget.render(this);
    // ...
  }
}

Proposed:

class AnyView {
  async render() {
    // ...
    let cleanup = widget.render({ model: this.model, el: this.el });
    // ...
  }
}

The key focus is on minimizing the API surface area by reducing the exposed fields to the user-provided render function. This change is expected to improve encapsulation and limit the potential for erroneous modifications.

In a review of current projects utilizing anywidget, no evident use-cases were identified that would be adversely affected by this change. It's worth mentioning that there's still a degree of uncertainty about how these changes will impact model (un)subscriptions within Backbone.

To-Do:

  • Investigate the potential impacts of this change on granular model subscriptions and unsubscriptions in Backbone.
  • Update documentation with new types

Request for Review:

I would like to invite reviewers to provide feedback, especially in areas related to Backbone's model (un)subscriptions. Any objections or observations on potential impacts are greatly appreciated.

cc: @maartenbreddels @juba @domoritz @kolibril13

@netlify
Copy link

netlify bot commented Jun 14, 2023

Deploy Preview for anywidget canceled.

Name Link
🔨 Latest commit e2d0b51
🔍 Latest deploy log https://app.netlify.com/sites/anywidget/deploys/648b2990335a6000085d22c1

@codecov
Copy link

codecov bot commented Jun 14, 2023

Codecov Report

Merging #138 (960916b) into main (8e58991) will not change coverage.
The diff coverage is n/a.

❗ Current head 960916b differs from pull request most recent head e2d0b51. Consider uploading reports for the commit e2d0b51 to get more accurate results

@@           Coverage Diff           @@
##             main     #138   +/-   ##
=======================================
  Coverage   97.14%   97.14%           
=======================================
  Files           8        8           
  Lines         420      420           
=======================================
  Hits          408      408           
  Misses         12       12           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Copy link
Contributor

@domoritz domoritz left a comment

Choose a reason for hiding this comment

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

Works for my use case.


/**
* @typedef AnyWidgetModule
* @prop render {(view: WidgetView) => Promise<undefined | (() => Promise<void>)>}
* @prop render {(view: { model: WidgetModel, el: HTMLElement }) => Promise<undefined | (() => Promise<void>)>}
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it odd that the variable is still called view here?

Copy link
Owner Author

@manzt manzt Jun 14, 2023

Choose a reason for hiding this comment

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

Ah yes, that's a good suggestion. Maybe a type like RenderContext or RenderProps would be better a more suitable type (variable names context or props respectively)

@manzt manzt marked this pull request as ready for review June 14, 2023 19:25
@juba
Copy link
Contributor

juba commented Jun 15, 2023

This would work for my use case, too.

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.

3 participants