Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement basic IO for the application #7

Open
stuf opened this issue Feb 1, 2017 · 1 comment
Open

Implement basic IO for the application #7

stuf opened this issue Feb 1, 2017 · 1 comment

Comments

@stuf
Copy link
Owner

stuf commented Feb 1, 2017

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.

@stuf stuf self-assigned this Feb 1, 2017
@stuf
Copy link
Owner Author

stuf commented Feb 1, 2017

For self-note, the chainability of FL-compatible libraries might seem like a good idea at first. Currently sanctuary is used out of curiosity for handling incoming data in network.js. This was actually written while on a HEL-OSL flight, which I decided to take into use.

In retrospect this part doesn't sit well in with the rest of the module, so optionally this could be rewritten with flow-static-land to ensure more consistent handling of borderline cases with API data. This mainly concerns the step between having received the data from the API and when parsing the data into use for the appropriate handlers.

I'll make a separate issue for this, since the way network data is handled currently (collecting the entire request to have all the relevant data for each request; rather, separate the request and response handlers to their own parts to do their respective part of the work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant