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

Lifecycle methods or non-view methods #266

Closed
maartenbreddels opened this issue Sep 4, 2023 · 3 comments
Closed

Lifecycle methods or non-view methods #266

maartenbreddels opened this issue Sep 4, 2023 · 3 comments

Comments

@maartenbreddels
Copy link

Hi,

right now, only a render method can be defined, which will be triggered when a view is created. It may also be useful to perform operations when a widget gets created (not a view), and when a widget gets destroyed. This allows for widgets similar to the one powering jslink etc.
Original questions that triggered this:
widgetti/ipyreact#44
cc @giswqs

@giswqs
Copy link
Contributor

giswqs commented Sep 4, 2023

@maartenbreddels Thank you for looking into this. There are so many JavaScript plugins available for leaflet. It would be a game-changer if we can make those plugins work with ipyleaflet through anywidget/ipyreact.

@manzt
Copy link
Owner

manzt commented Sep 11, 2023

Thanks for opening the issue. This is something that I've been thinking about for some time and a use case I want to support, but I haven't settled on an API because I want to make sure we can handle other use cases. Thanks for sharing the one from @giswqs!

One thing that I'd been considering is something like setup (name TBD):

export function setup() {
   // runs when model is created
   return {
     data: "...",
     foo: 100,
   };
}

export function render({ model, el }, context) {
  let { data, foo } = context;
}

A pattern I've observed in Jupyter Widgets is that there is some "data" that often gets appended to the DOMWidgetModel on initialization, and then views expect/mutate this data (but not with the on/off methods). So I've been considering an API where a setup function can do some initialization logic, but then also create some data that can be referenced mutated by other views.

I'm a bit nervous about passing around data this way and introducing a confusing mental model. So, perhaps to start we can think about just introducing a "setup" hook and later decide if it can return any state to pass around to views.

@manzt
Copy link
Owner

manzt commented Dec 2, 2023

Looking for feedback on #395

@manzt manzt closed this as completed Jan 26, 2024
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

No branches or pull requests

3 participants