Referencing properties of an object's parent class from inside the child object

Suppose I have four tabs to display in an Angular component, each with its own rule for whether to display it. Here's a very abstract depiction of the situation.

export class View {
  foo: true;
  bar: false;
  tabs: {
    'A': { order: 1, get isVisible() { return this.foo; } },
    'B': { order: 2, get isVisible() { return !this.bar; } },
    'C': { order: 3, get isVisible() { return this.foo && this.bar; } },
    'D': { order: 4, get isVisible() { return !this.foo || this.bar; } }
  };
};

This doesn't work because this refers to the tabs object, not to the View object that contains it. But the criteria for display the respective tabs depend on properties of the View object.

I figured this is a better and more maintainable way to organize my tabs than defining the properties directly inside the View in this manner:

export class View {
  foo: true;
  bar: false;
  get isTabAVisible() { return this.foo; }
  get isTabBVisible() { return !this.bar; }
  // etc.

Is there a way to organize this to get the outcome I'm looking for?

Any time you come across a situation where the natural approach doesn't fit the programming paradigm, it's time to re-evaluate whether you are using the correct one (either the approach needs to change to fit the paradigm, or the you need to pick a paradigm that works with your approach). Isn't this arguably better:

type TabState = {
  foo: boolean
  bar: boolean
}

const state: TabState = {
  foo: true,
  bar: false,
}

enum TabOrder {
  A,
  B,
  C,
  D,
}

type Tab = {
  order: TabOrder
}

const isVisible = ({ foo, bar }: TabState, tab: Tab): boolean => {
  switch (tab.order) {
    case TabOrder.A: return foo;
    case TabOrder.B: return bar;
    case TabOrder.C: return foo && bar;
    case TabOrder.D: return !foo || bar;
  }
}

Playground

This is easier to test (pure function of only it's arguments), well-typed, easier to debug, etc. etc. I know the received wisdom is that OO is well-suited for UI work, that doesn't mean the received wisdom is correct. Note that if you're locked in to OO by a framework or the existing codebase you can always make it a static method of the class.

You're starting off by defining a class, but then switches to a syntax of an object literal. Beside the code being invalid, I think that confusion is part of the problem - a class isn't an object, it's a set of instructions for creating an object.

If we first fix the syntax of your first snippet, it would look like this:

export class View {
    foo = true
    bar = false
    tabs = {
      'A': { order: 1, get isVisible() { return this.foo; } },
      'B': { order: 2, get isVisible() { return !this.bar; } },
      'C': { order: 3, get isVisible() { return this.foo && this.bar; } },
      'D': { order: 4, get isVisible() { return !this.foo || this.bar; } }
    }
  };

After doing that, we can switch to use an explicit constructor in order to get a reference to the object being constructed, and use it inside the constructed methods:

export class View {
    foo = true
    bar = false
    tabs

    constructor() {
      const _this = this;
      this.tabs = {
        'A': { order: 1, get isVisible() { return _this.foo; } },
        'B': { order: 2, get isVisible() { return !_this.bar; } },
        'C': { order: 3, get isVisible() { return _this.foo && _this.bar; } },
        'D': { order: 4, get isVisible() { return !_this.foo || _this.bar; } }
      }
    }
  };

When an object instance would be created by new View(), the methods that would be created under the tabs field would reference the properties of the new object.