Program Organization

Organization

Style Guide

ESLint is used for code style under mostly the default settings. It can be really annoying, but please try to live with it. I forced myself to use it for this project and the code actually looks halfway decent. One note is that I am breaking some conventions here with name styling:

• Class names, function names, and element names are styled in CamelCase. Note that Vue.JS automatically converts CamelCase element variables to kebab-case styling for HTML
• Variables should be styled in kebab-case
• The rationale is that it's easy to tell what can be mutated (kebab-case can be mutated and assigned) and what can't (Do not re-assign or mutate CamelCase things). I also think its easier to read, so its kind of just a personal preference

Directory Structure

• algorithms -- A directory for possible algorithms in case I ever want to develop others. This is more of an organizational thing
  • /logootish -- The logootish algorithm that I developed. This is the more interesting of all the directories
    • /index.js -- The main Logootish algorithm
    • /bst.js -- A custom binary sorting tree that supports custom compare functions and supports getting groups of nodes. This is used to select regions of nodes to consider. This may need a rewrite
    • /ints.js -- A custom Int32 type. I implemented this so that any int-based type would have a standard interface using methods rather than operators because JavaScript doesn't support operator overloading. In the future, it would be possible to replace the Int32 type with any other int type because of this interface. Because it's only an Int32, the document will have issues if you add 2^31 characters consecutively, but then again so will most web browsers :)
    • utils.js -- Random utilities that I should move somewhere else. This includes Enum, arraymap, PeekableIterator, and FatalError
• components -- Vue components
• layouts -- Nuxt layouts. This consists of the gradient background layout, which is for the login page, and the default layout, which watches the Matrix client state for a sign out. I could use Nuxt.JS middleware for this, but it's more efficient to use watchers since they can actually detect state changes
• pages -- Nuxt pages
• plugins -- Nuxt plugins that perform vital functions for the program that are not the algorithm or the Vuex store
• static -- Static files, such as the site icon and logo
• store -- The Vuex store. This is used for UI only since I want the algorithm to be seperate from Vue.JS. Vuex does track the state of the Matrix client, but not the state of document nodes (that's all "traditional" ES6 JS)
• test -- A directory that I have reserved for unit testing. This would help a lot if I actually implemented it. sigh