membrane_core icon indicating copy to clipboard operation
membrane_core copied to clipboard

Consider adding non-strict versions of some actions

Open mat-hek opened this issue 4 years ago • 1 comments

In some cases, it doesn't make sense or it's hard to make sure that some action's parameters are correct, for example, if a child being removed wasn't already removed. It may be beneficial to introduce strict and non-strict versions of some actions, that would be ignored and wouldn't crash in such cases, for example: remove_child and remove_child! or try_remove_child and remove_child. The problem with that approach is the risk of silently ignoring particular actions because of some error, like a typo in a child name. I don't see a perfect approach in this case. We could:

  • Not care. It's no worse than the current solutions that usually look like
actions = if child in ctx.children, do: [remove_child: child], else: []
  • Keep a list of n previously removed children and warn if the affected child is not there
  • Enforce a pattern on the children naming, for example (name :: atom) | {name :: atom, id :: any}. Then we could keep all the names ever created and warn if the affected child has a different name.

mat-hek avatar Nov 18 '21 17:11 mat-hek

I think it is a good idea, although I would lean towards using ensure_<something> pattern to name those actions, taking inspiration from Application.ensure_started.

Maybe even more useful would be ensure_timer_stopped. I'm not sure if timers are accessible from context, but I never found it there and had to keep a set of timers in element's state and remember to update the state whenever I do anything with them. That's unnecessary complexity when you just want to make sure you won't get any more ticks.

I would also like to point out that if we were to do #349, we would end up with 6 actions that remove child. That is a bit much and naming would get interesting too: supervised_ensure_child_removed. Maybe it's time to consider modifying the API to allow passing options to actions. Enforcing a pattern for children naming would certainly aid that

daniel-jodlos avatar Nov 19 '21 08:11 daniel-jodlos

This has been mostly addressed by introducing children groups, as operating on them removes the need to conditionally remove children in most places. Please reopen if this happens to be not enough.

mat-hek avatar Jan 19 '24 15:01 mat-hek