#Is banana in a box better than rxjs and signals

25 messages · Page 1 of 1 (latest)

worldly charm
#

So my manager wants us to stop using rxjs and signals and instead just use banana in a box two way binding for everything. Especially since this is what he is used to from angularJS

Is this a good idea? Is two way binding better than using rxjs and signals?

red sedge
#

banana in the box is a communication solution between components: rxjs and signals are not.

worldly charm
#

(is his argument, not mine)

red sedge
# worldly charm Yeah, that's what I figured too, trying to figure out the best way to explain it...

two way data binding is a channel for data.
You still need a data reference somewhere. It might be stored in a variable or a signal.
There is nothing wrong about storing it in a signal, you might even get benefits with computed signals.
But they do not want, well so...

But I do not understand why they mention rxjs: it's totally unrelated.
It would require snippets with/without to understand their logic.

worldly charm
# red sedge two way data binding is a channel for data. You still need a data reference some...

Option 1

ParentComponent {
  fruit = "orange"

  changeFruit(input: string)
  {
    this.fruit = input;
    this.changeDetectorRef.markForCheck(); // maybe needed??
  }
}

ChildComponent {
  @Input() fruit: string;
  ngOnChanges(changes) {
    if (changes.fruit) this.changeSomethingElse();
  }
}

Option 2

ParentComponent {
  fruit: BehaviourSubject<string>;
// or signal?
}

ChildComponent {
  @Input() fruit: Observable<string>;
  somethingElse = this.fruit.pipe(map(this.changeSomethingElse));
}
#

Something like this I guess

#

Obviously input bindings are used in both cases, but one is using a lifecycle hooks instead of rxjs

#

And a real example would probably be much more complex than this

worldly charm
#

For two way binding:

Option 1

ParentComponent {
  fruit = "orange"

  someParentFn(input: string)
  {
    this.fruit = input;
    this.changeDetectorRef.markForCheck(); // maybe needed??
  }
}

ChildComponent {
  @Input() fruit: string;
  @Output() fruitChange = new EventEmitter<string>();
  ngOnChanges(changes) {
    if (changes.fruit) this.changeSomethingElse();
  }

  someChildFn(input: string)
  {
    this.fruit = input;
    this.fruitChange.emit(input);
  }
}

Option 2

ParentComponent {
  fruit: BehaviourSubject<string>;
// or signal?

  someParentFn(input: string)
  {
    this.fruit.next(input);
  }
}

ChildComponent {
  @Input() fruit: BehaviourSubject<string>;
  somethingElse = this.fruit.pipe(map(this.changeSomethingElse));

  someChildFn(input: string)
  {
    this.fruit.next(input);
  }
}
red sedge
#

The issue is you are comparing apples with bananas. As called, two way data binding is for two way data binding.
So simple variables, signals or observables, if you need the child to get and emit data, choosing signals or observables is unrelated

worldly charm
#

So either this.changeSomethingElse() modifies something else in the child imperatively, or it's done via the rxjs map operator

red sedge
#

There might be choices about your data itself indeed, but that's unrelated to the communication itself between components.

worldly charm
red sedge
#

And from my experience, 2 way data binding itself is not that common, i never used it in 6 years because the contract between a parent and a child might be always that simple.

worldly charm
#

Yeah, I haven't found it common either

worldly charm
red sedge
#

But to answer to the first question from your manager, he's right: do not pass a transporter as a way to send data back to the parent.

worldly charm
red sedge