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

A better (?) function for debugging #2

Open
mindplay-dk opened this issue Sep 2, 2019 · 1 comment
Open

A better (?) function for debugging #2

mindplay-dk opened this issue Sep 2, 2019 · 1 comment

Comments

@mindplay-dk
Copy link

Section 5.1 shows a tapProgram HOP that lets you add an onChange event-listener to a program.

I was pondering intergration with Redux DevTools, and found this a bit limited, since it doesn't let you observe the actual messages - only the resulting state.

I ended up with this instead:

function observe(program, onUpdate) {
  return {
    ...program,
    update: (message, state) => {
      var newState = program.update(message, state);
      onUpdate(message, newState);
      return newState;
    }
  }
}

For example, this lets you see every message and resulting state in the console:

var program = { /* ... */ };

program = observe(program, (message, state) => console.log("☑", message, state));

This is already quite useful for debugging - I feel like the reason for a change is likely going to be interesting if you're monitoring an app for changes, so maybe consider changing this is section 5.1?

@mindplay-dk
Copy link
Author

Side question: the tapProgram example HOP uses a return statement:

function tapProgram (program, onChange) {
  return {
    ...program,
    view (model, dispatch) {
      onChange(model)
      return program.view(model, dispatch) // <--- ?
    }
  }
}

The framework doesn't seem to expect any return-value from view functions?

Maybe this is a historical artifact from a time when this was a way of doing effects? Today, it seems, the view can simply dispatch if rendering the view has side-effects. (?)

It's a bit confusing and should probably be removed either way?

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

No branches or pull requests

1 participant