superhawk610

<!-- livebook:{"autosave_interval_s":null} -->

# Teller Bank Challenge

```elixir
Mix.install([:req, :jason, :kino])
```

## Your Solution

superhawk610

use std::mem::MaybeUninit;
use unsafe_libyaml::*;

fn main() {
    unsafe {
        let input = "foo: bar\nbaz: garply\n";
        let mut parser: MaybeUninit<yaml_parser_t> = MaybeUninit::uninit();
        let mut ev: MaybeUninit<yaml_event_t> = MaybeUninit::uninit();

        check_err("[init]", yaml_parser_initialize(parser.as_mut_ptr()));

superhawk610

Guppy implements a task queue for any actions that require exclusive access to the project's package.json and/or node_modules folder. This currently includes dependency installation & uninstallation.

The queue has the following structure:

{
  [projectId: string]: Array<{
    action: 'install' : 'uninstall' : 'modify',
 active: true | false,

superhawk610

/* ... */    
case QUEUE_MODIFY_PROJECT: {
  const { projectId, settings } = action;

  return produce(state, draftState => {
    // get existing project queue, or create it if this
    // is the first entry
    const projectQueue = draftState[projectId] || [];

    // get existing modification queue for this project, or

superhawk610

Let's walk through adding a new dependency - I think that's complex enough without being too much to grasp:

• User clicks Add to Project after searching for and finding a dependency
• ADD_DEPENDENCY_START action is fired using addDependencyStart action creator
• ADD_DEPENDENCY_START workflow from dependency.middleware is fired
• this, in turn, fires off installDependency from dependencies.service
• dependencies.reducer updates the state for that project to indicate that the new dependency is installing
• installDependency spawns a child shell process to actually run yarn add lodash or whatever
• the dependency finishes installing, which resolves the Promise returned by installDependency and moves to the next step of the middleware, loadProjectDependency
• loadProjectDependency (from read-from-disk.service) loads the specifics about the newly installed dependency and dispatches them as an ADD_DEPENDENCY_FINISH action using the addDependencyFinish action creator

superhawk610

On a basic level, middlewares are responsible for handling side effects of redux actions - they fit, as their name would imply, in the middle of the redux chain. Our setup for Guppy looks something like this:

action -> store
            |
        middleware
            |
        middleware
            |
 middleware

superhawk610

// @flow
import { ipcRenderer } from 'electron';
import * as childProcess from 'child_process';
import {
  RUN_TASK,
  ABORT_TASK,
  COMPLETE_TASK,
  LAUNCH_DEV_SERVER,
  completeTask,
  attachTaskMetadata,

superhawk610

040b698155c4b53deec6571ff98336776973a7f408f1550fae3b4c4f8a068075b8591f85a59817722f9fc62cca31e0ab54482f67196859192c5d3e57a59b9638fa

superhawk610

/**
 * Functional Programming!!!
 */
const val = 5,

  /**
   * The identity function takes a function and returns a copy of that function.
   * The use of the spread (...) operator here is key to understanding more
   * complex functional programming, like curry() below.
   */

superhawk610

Keybase proof

I hereby claim:

• I am superhawk610 on github.
• I am superhawk610 (https://keybase.io/superhawk610) on keybase.
• I have a public key ASD-DVk9BqhTTLcD1ICJlz1G2F0PrZevWGGkvozaAgGdoQo

To claim this, I am signing this object: