stuf / masayards-calmm Goto Github PK

Migrate into using something to the line of stylized components. Having a load of separate CSS files and using them in this way makes me hurt a little.

We should move away from the class-based mess currently residing in the webview component for displaying the game view.

The network data handler currently located in the game module has the smell of legacy. The core functionality is modeled based off of the old "Dockyard" project, which itself was an implementation to the notes of "it works, move on", while investigating the debugger protocol in Electron.

Clean up the structure of the code, and split up the functionality into isolated pieces of code that can do work on their own, independent of others.

Additionally, investigate why the debugger events aren't Kefir streams, and if there is a way, convert those. This should help keep the code a little bit cleaner in terms of managing event subscriptions and when having to dispose of said event streams (in contrast to .on/.off etc).

The main.development.js is currently a mess, as it's just had minimal changes/additions to it ever since forking it from electron-react-boilerplate.

Might be a good idea to move out the pre-init (command-line args) and Window-related configuration (application menu) to their own files.

Currently the contents of the app-ui module is a bit of a mess. Clean up the components so that the necessary helper functionality resides in its own meta file, and create a file structure for the components themselves.

(Probably something related to distributing PepperFlash, worth looking up anycase)

Allow for looking up the PepperFlash plugin from a local Chrome installation, instead of terminating process with 17.

I'm not entirely sure why I didn't do this in the first place. All of the lists of data that we add listeners for processing could be made into maps instead. This way, there's no need to use L.find or make any other intermediate steps when creating a final presentable object.

As an example the ever-so-lovely Fleet model; it contains a list of unique IDs that point toward an object in the player roster. Additionally, a player Ship object is not yet final—it only contains the player-specific data, such as equipment, level-specific stats, experience and so forth—so it doesn't contain things like the name, class and base stats that might be needed for stat calculation, among other things.

The current UI in the client is more of a proof of concept, using Semantic UI. There's a lot of redundant fluff and assumptions on the framework's side.

So, let's create a nicer prototype UI that can be styled appropriately.

There might be some alternatives on how to cleanly manage application IO. Some uses for a nicer managed IO scheme includes taking a screenshot, import and export of data and desktop notifications, are first that come to mind.

Some interesting alternatives for this:

• IO typeclass in flow-static-land
• Alternatively, ramda-fantasy's IO based on the Fantasy Land spec

Do some testing with these and see how things could work out. At least based on some looking around, thestatic-land implementation offered in flow-static-land seems like it could be a good pick, as parts of Calmm as well as Kefir supports static-land algebraic types, as well as the added benefit of static type checking with Flow.

Create a basic set of documentation that can work as reference for both the incoming data from the game API as well as document the data types and structures used internally in the application. Additionally, supply some model data that can also be used for creating tests.

This is a huge time-saver, since this will allow for tests to be written out and have the handling of data tested without having to trigger API actions to see if something works or not. Especially in the case of some actions that can only be done a limited amount of times during a day.

This is an idea for future improvement. Since the state can be kept better up to date right now, so it might not be a requirement any more to do things the way they currently are being done.

Currently a network event is processed roughly as follows:

• Network.requestWillBeSent — take the requestId and the request object (because we need the postBody from the request), and save it into the state, associated by requestId
• Network.responseReceived — take the requestId and response and save into the state, again associated with requestId
• Network.loadingFinished — take the requestId and fetch the request and response objects from state, after which the completed request can be removed from the state
• After we have the required data and the response loading has finished, send the debugger a getRequestBody message containing the requestId to retrieve the response body, which will contain the API data
• Trim out unnecessary prefix from the URL, this is going to be used for calling the correct handlers
• Trim out the prefix from the body, so that it can be parsed into JSON
• Parse body and postBody
• Remove any sensitive stuff from the data (incl. token)
• Collect this data into an object that will be pushed into the game.api.latest, where a subscriber will pick this up and delegate it to the correct handler

The request and response phase can probably be split into their own handlers to reduce the overall complexity of the network handler. That way the state can be updated (and possibly also staged) in preparation before the response is entirely loaded.

Notes

The usual cases for needing the POST body would be when editing fleet composition, performing actions (construction, repair, quest completion, etc), where only usually only requests that affect the player ship roster or equipment list will involve some larger data manipulation where optimisation can be beneficial.

As a note-to-self for the future (writing it down so I'll get it out of my head), for example quests are structured in a way, where a map could be implemented in displaying relationships; a quest a may have quests b, c as its prerequisites before it's available. Probably a good excuse to look into the world of search trees.

Everything is so under-tested right now that it's not even funny. Do something about it!

• Network event life-cycle tests
• Game state handling/transformation tests
• e2e tests for app
• Tests for main process

I think this probably breaks due to karet being used instead of react, when testing components with something like enzyme, because using Observable-based components with enzyme with e.g. shallow rendering results in the familiar Invariant Violation: Objects are not valid as a React child error being thrown.

As described in #12, the game data is divided into two different parts; the base data and the player data. When displaying an entity that requires both parts for display (a Fleet's list of Ships), they should just have to make a simple call with the id, which will be used for lookup.

• Also, look if this could be a good candidate for using L.concat (or L.concatAs)