Skip to content

Base Classes and namings:

CoComponentBase:

  • Legacy class, we used to use the Co/Mo model similar to old angular, where the Co would load the Skin (html file) into a div that it was given.

  • Classes would extend CoComponentBase and use it, they had to pass along the div where it would be created, and sometimes the skin (other times it would just hardcode the skin class).

  • It has performance issues, and is just not convenient to work with (no HMR to start, html is separate, so you need to keep track of multiple files, hard to extend properly because of skin overlaps etc).

  • Old legacy Co prefix at the beginning of files.

  • There’s a lot of classes with Mo in their name that are don’t extend CoComponentBase, these are legacy and bad and should be renamed eventually.

MoModelBase:

  • Legacy class, the Mo to the Co. The Co would contain the skin and get all of the divs/buttons with getElementById (or getPart as it was called) and the Mo would be in charge of the logic.

  • Classes would extend MoModelBase and use it, it had some utilities built in, such as EventListeners and active.

  • Old legacy Mo prefix at the beginning of files.

  • There’s a lot of classes with Mo in their name that are don’t extend MoModelBase, these are legacy and bad and should be renamed eventually.

ItemRenderer and ArrayCollection:

  • Legacy Code.

  • ItemRenderer was an item in a list. It extended Co and was passed a skin.

  • ArrayCollection is how we would have collections (lists), you would need a CoList and an ArrayCollection and it would create all items passed to it as the Ir class defined in the CoList.

  • It had a lot of performance issues, and usability issues, which prompted a few follow up classes like PagingCollection and RecordCollection and PagedRecordCollection, but please just don’t use any of these we don’t want new Co/Ir classes.

  • Old legacy Ir prefix at the beginning of ItemRenderer files.

EventDispatcher:

  • Classes can extend it to have “addEventListener”, “remoeveEventListener” and “dispatchEvent”. Usually Data classes (prefix Da) would extend it to be able to send events to classes who listen to them.

  • Nowadays we should use mobx instead and just listen to the changes directly if possible or send events directly as Lit elements are html elements and can dispatch events.

Sk Files:

  • Legacy code.

  • Skin files, were used to let Co/Ir classes know what HTML file to load. These are just html files put in the public directory.

Da Files:

  • Data files, usually mostly for types or parsing data from backend vo’s.

  • There’s a lot of Da files that are just basically a singleton with a ton of imports, that is bad and we’re working on updating and changing them.