Compared to the unidirectional association app, we have to deal with a number of new technical issues:

Code each class of the JS class model as an ES2015 class with implicit getters and setters (or, alternatively, as an ES5 constructor function with explicit setters):

These steps are discussed in more detail in the following sections.

For instance, the Publisher class from the JS class model is coded in the following way:

class Publisher {
  constructor ({name, address}) {
    this.name = name;
    this.address = address;
    // derived inverse reference property (inverse of Book::publisher)
    this._publishedBooks = {};  // initialize as an empty map
  }
  get name() {...}
  static checkName( n) {...}
  static checkNameAsId( n) {...}
  static checkNameAsIdRef( n) {...}
  set name( n) {...}
  get address() {...}
  static checkAddress( a) {...}
  set address( a) {...}
  toString() {...}
  toRecord() {...}
}

Notice that we have added the (derived) multi-valued reference property publishedBooks, but we do not assign it in the constructor function because it is a read-only property that is assigned implicitly when its inverse master reference property Book::publisher is assigned.

Any setter for a reference property that is coupled to a derived inverse reference property (implementing a bidirectional association), now also needs to assign/add/remove inverse references to/from the corresponding collection value of the inverse reference property. An example of such a setter is publisher in the Book class:

set publisher( p) {
  if (!p) {  // the publisher reference is to be deleted
    // delete the inverse reference in Publisher::publishedBooks
    delete this._publisher.publishedBooks[ this._isbn];
    // unset the publisher property
    delete this._publisher;
  } else {
    // p can be an ID reference or an object reference
    const publisher_id = (typeof p !== "object") ? p : p.name;
    const constraintViolation = Book.checkPublisher( publisher_id);
    if (constraintViolation instanceof NoConstraintViolation) {
      if (this._publisher) {
        // delete the inverse reference in Publisher::publishedBooks
        delete this._publisher.publishedBooks[ this._isbn];
      }
      // create the new publisher reference
      this._publisher = Publisher.instances[ publisher_id];
      // add the new inverse reference to Publisher::publishedBooks
      this._publisher.publishedBooks[ this._isbn] = this;
    } else {
      throw constraintViolation;
    }
  }
}

For any multi-valued reference property that is coupled to a derived inverse reference property, both the add and the remove method also have to assign/add/remove corresponding references to/from (the value set of) the inverse property.

For instance, for the multi-valued reference property Book::authors that is coupled to the derived inverse reference property Author:authoredBooks for implementing the bidirectional authorship association between Book and Author, the Book::addAuthor method is coded in the following way:

addAuthor( a) {
  // a can be an ID reference or an object reference
  const author_id = (typeof a !== "object") ? parseInt(a) : a.authorId;
  const validationResult = Book.checkAuthor( author_id);
  if (author_id && validationResult instanceof NoConstraintViolation) {
    // add the new author reference
    this._authors[author_id] = Author.instances[author_id];
    // automatically add the derived inverse reference
    this._authors[author_id].authoredBooks[this._isbn] = this;
  } else {
    throw validationResult;
  }
}

For the remove operation removeAuthor we obtain the following code:

removeAuthor( a) {
  // a can be an ID reference or an object reference
  const author_id = (typeof a !== "object") ? parseInt(a) : a.authorId;
  const validationResult = Book.checkAuthor( author_id);
  if (validationResult instanceof NoConstraintViolation) {
    // automatically delete the derived inverse reference
    delete this._authors[author_id].authoredBooks[this._isbn];
    // delete the author reference
    delete this._authors[author_id];
  } else {
    throw validationResult;
  }
}

In the object-to-storage conversion of a publisher or author object with toRecord(), the derived properties publishedBooks and authoredBooks are not included since their information is redundant (derived from the publisher and authors properties of books). For instance, the Author::toRecord function is coded in the following way:

toRecord() {
  var rec = {};
  // loop over all Author properties
  for (let p of Object.keys( this)) {
    // keep underscore-prefixed properties except "_authoredBooks"
    if (p.charAt(0) === "_" && p !== "_authoredBooks") {
      // remove underscore prefix
      rec[p.substr(1)] = this[p];
    }
  };
  return rec;
}

When a Book instance b, with a single reference b.publisher to a Publisher instance p and multiple references b.authors to Author instances, is destroyed, the derived inverse references have to be removed first (e.g., by removing b from p.publishedBooks):

Book.destroy = function (isbn) {
  const book = Book.instances[isbn];
  if (book) {
    console.log( book.toString() + " deleted!");
    if (book.publisher) {
      // remove inverse reference from book.publisher
      delete book.publisher.publishedBooks[isbn];
    }
    // remove inverse references from all book.authors
    for (let authorID of Object.keys( book.authors)) {
      delete book.authors[authorID].authoredBooks[isbn];
    }
    // finally, delete book from Book.instances
    delete Book.instances[isbn];
  } else {
    console.log(`There is no book with ISBN ${isbn} in the database!`);
  }
};