mikaelbr / bacon-love

A Nodeschool type workshop for Functional Reactive Programming and Bacon.js

Hei! 🐙

I do podcasts, Open Source and working on local development community efforts.

Blogs

• blog.mib.im

Podcasts (norwegian)

• Kortslutning – All about the life as developers. Oriented towards soft skills
• BartJS Podcast – Podcast on all things JavaScript
• Lesehesten – Periodically released podcasts discussing programming books and articles

Programming videos (norwegian)

• Kodesnutt
• OCaml series

bacon-love's Issues

Exercise 14: Problem statement unclear about requirements

There are three problems that might be confusing (because I ran up against it):

Current problem statement:

You will be supplied with streams of two different input-fields, each with their own validation function which takes a value as input and returns whether the value is valid or not.

What you should return is three observables which indicate whether the value observed is valid or not and an observable which indicates whether the field as a whole is valid.

Field A and C is required. Field B is optional, but if it has a value it must be valid.

Minor Typo

The problem statement says we are supplied with streams of two different input fields, but there are actually three that we deal with. I am guessing that this is a typo.

toProperty() is required

The problem statement only specifies that we return observables indicating the validity of the form and fields. Although it may be clear to the experienced user that form validation results should be in the form of properties, I initially tried to submit the answer without converting the eventStreams to properties and got a cryptic error instead.

Consider adding a phrase in the problem statement to explain that the result should be a property because of the nature of the application. Or alternatively, add an extra test case to confirm that this is the case.

Initial value to toProperty() is required

This is a little bit unintuitive because the problem statement does not say anything about initial values. In fact, at the time, I didn't even know that the toProperty() method could take an initial value as parameter.

If you submit the answer without specifying an initial value for the toProperty() method, you still get all the green checkmarks from the tests, but it won't actually verify the answer.

Adding this to NodeSchool.io

Hey,

how about adding this to the NodeSchool page? There's no reactive workshopper yet.

Best,
Finn

Excercise 11: Official solution fails due to incorrect test cases

module.exports = (Bacon, nidelva, leirelva, buttonClicked) =>
        nidelva
            .combine(leirelva, (leirelvaSample, nidelvaSample) => leirelvaSample + nidelvaSample)
            .sampledBy(buttonClicked);

✓ Should return an event stream
✓ Should make an EventStream from samples with the sum of the two rivers on click
✗ Should emit values every time button is clicked and give the sum of the two rivers on click

It seems last test expects return of Property, but not EventStream.

module.exports = (Bacon, nidelva, leirelva, buttonClicked) =>
        nidelva
            .combine(leirelva, (leirelvaSample, nidelvaSample) => leirelvaSample + nidelvaSample)
            .sampledBy(buttonClicked) 
            .toProperty();

Cannot verify solutions

Hello there,

Here is what I get when trying to run the solutions:

/home/martin/.config/yarn/global/node_modules/bacon-love/verify.js:95
  return !!obj.onValue && !!obj.log;
              ^

TypeError: Cannot read property 'onValue' of undefined
    at isProbablyBaconInstance (/home/martin/.config/yarn/global/node_modules/bacon-love/verify.js:95:15)
    at run (/home/martin/.config/yarn/global/node_modules/bacon-love/verify.js:74:10)
    at Exercise.<anonymous> (/home/martin/.config/yarn/global/node_modules/bacon-love/verify.js:44:14)
    at next (/home/martin/.config/yarn/global/node_modules/workshopper-exercise/exercise.js:188:19)
    at /home/martin/.config/yarn/global/node_modules/workshopper-exercise/exercise.js:195:7
    at /home/martin/.config/yarn/global/node_modules/workshopper-exercise/execute.js:110:7
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Content license for bacon-love?

Hi @mikaelbr, really love what you've put together. I was wondering how this content was licensed, and if it would be OK to create a derivative work using RxJS?

Exercise 9: Problem statement unclear about Sector5

Reading the story, it's a little confusing and it's not fully obvious that we should always include zero in the report for sector5.

I suggest we add a sentence to the problem stating that:

"Since no EDF ships are deployed to sector 5, that part of the report should always return zero"

I was completely stumped because I thought it was a typo that we had to report on sector 5, yet we didn't have an incoming stream for it. Eventually, I had to open up the solution file to see what I was missing.

I can file a PR for this if the maintainers of this repo agree with my assessment. Further discussion is welcomed.

How to complete exercise 1?

Exercise demands a stream(?) of values that add up to 6, without introducing baconjs at all. Should I go through the baconjs documentation myself? I thought the whole point of the workshop was to guide one through the FRP paradigm using a DIY approach with baconjs..

Exercise 10: Solution is unnecessarily complex

This is the current solution for Exercise 10:

module.exports = (Bacon, riverFlow, inCriticalMode, isOnBreak, isSingleGate, systemActive, riverFlowLimit) => {
    const isTooMuchWater = riverFlow
        .map(flow => flow > riverFlowLimit)
        .toProperty();

    const isAllowedToNotify = isOnBreak.not()
        .and(
            inCriticalMode.or(systemActive.and(isSingleGate))
        );

    return isTooMuchWater.and(isAllowedToNotify);
};

This is my proposed solution:

module.exports = (Bacon, riverFlow, inCriticalMode, isOnBreak, isSingleGate, systemActive, riverFlowLimit) => {
  const limitExceeded = riverFlow.map(flow => flow > riverFlowLimit);
  const notOnBreak = isOnBreak.not();

  const shouldReport = systemActive
    .and(notOnBreak)
    .and(isSingleGate)
    .or(inCriticalMode);

  return shouldReport.and(limitExceeded);
};

I believe my solution to be:

• A lot neater and easier to read;
• More linear and does not require nesting of any kind, and;
• No unneeded toProperty() call (in fact, the user doesn't even know that riverFlow isn't a property anyway.

I can file a PR for this if the maintainers of this repo agree with my assessment. Further discussion is welcomed.

Excersise 2: returns without error but not completed

1. Wrapping Values as Reactive Datatypes
   Exercise 2 of 16
   returns without error but not completed if array is explicitly described :
   Bacon.sequentially(2,[1,2,3,4])

if I use the callback function that passed excersise 1of 16 instead (tested to generate a four element array that sums to 10):

✗ Your array event stream should have 4 values.
✗ Your array items should sum up to 10.

Require Node.js 4?

This does not apply to the latest release on npm, but only to the master branch, and should be resolved before releasing the next version.

When running bacon-love run or bacon-love verify under Node.js 0.12, it works fine if the user's program only uses ES5. However, if the user follows the instructions given and uses ES2015 language features in their program, they get this non-helpful error:

✗ Could not find your file. Make sure the path is correct.

What should happen, is to either give them a better error message, or simply require Node.js >=4 to run bacon-love at all.

I think it will be non-trivial to handle the error correctly, because it has to do with Babel and how it handles the user's file. My recommendation is that we add a hard requirement on Node.js >=4. What do you think @mikaelbr?