I added this as a comment on @schempy's PR last week, but it was after it was closed and I think people missed it (#4 (comment)).

Here it is again:

I ran into a problem when trying to update the flappy bird example app to use translate and rotate. The problem is that the way these transformations are performed in a canvas is reminiscent of how these things have been done in computer graphics since the 90s (I would guess). That means there's a hidden state in the canvas with all the transformations done so far. You can see it in the example for rotate in MDN: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Transformations#A_rotate_example

There you'll see that, to rotate the square around the center where it's going to be drawn, you have to:

• translate to the middle of where you'll draw the square (offsets + half the width/height)
• rotate the angle you want
• translate back (just -1 * the numbers of the first step)
• draw the square

I dislike this as it creates a cognitive overhead where you have to mentally do the transformations in your head to figure out if they are correct (specially when they are not, as there's a good chance the thing you wanted to draw is going to be off screen and it's harder to figure out which step is the problem).

Some options to approach this problem that I can think of:

1. just expose what the canvas api implements, and let the user of the driver deal with transformations and states;
2. expose the 'low level' api for now, and build abstractions on top of it (for example a rotateAround that does that rotate around a specified coordiante)
3. come up with a way to delay applying the transformations, and then process them all in one go so they 'do the right thing'
4. read up and see if anyone figure out a way to do these type of transformations in a functional way.

How it could like for 1:

group([
  saveState(),
  translate({x: 55, y: 55}),
  rotate({angle: 0.5}),
  translate({x: -55, y: -55}),
  rect({x: 50, y: 50, width: 10, height: 10, draw: [{fill: 'black'}]),
  restoreState()
])

How it could like for 2:

rotateAround(
  {x: 55, y: 55, angle: 0.5},
  [
    rect({x: 50, y: 50, width: 10, height: 10, draw: [{fill: 'black'}])
  ]
)

I'm not sure how it could look like for 3 or 4. One thing that I believe is that these approaches are harder to do having the transformations being attributes to regular draw elements (they would have to be a list to allow the process demonstrated here).

Thoughts?

While this is not clearly documented in any way (which is a thing that should also be fixed, possibly while fixing this), it seems very sensible that makeCanvasDriver's second argument should be optional, assuming you supply its first argument.

The reasoning behind this is that the first argument causes the driver to attach to an existing canvas, which already has its own width and height, making specifying them redundant if not counterproductive.

What happens presently is that the builder method throws a type error as it assumes the second argument has a value and tries to access its properties.

@Widdershin

TypeError: xstream_1.default.fromObservable(sinks[name]).subscribe is not a function.

The code in main.js:

import { run } from '@cycle/run';
import { makeCanvasDriver, rect, text } from 'cycle-canvas';
import xs, { stream } from 'xstream';

function main(sources) {
const obj = {
Canvas: xs.of(
rect({
x: 10, y: 10, width: 160, height: 100,
draw: [{ fill: 'purple' }],
children: [
text({x: 15, y: 25, value: 'Hello World!', font: '18pt Arial', draw: [{ fill: 'white' }]})
]
})
)
};
return obj
}
const drivers = {
Canvas: makeCanvasDriver(null, { width: 800, height: 600 })
};
run(main, drivers);

Thank you for your work pretty much!

It seems the link to flappy bird example is broken :(

Often in game development you want to be able to use external images. Canvas supports drawing images, so we can as well.

Build some cool little canvas examples to show how to use this library:

Off the top of my head, it would be cool to have some retro games like Pong or Asteroids.

Anyone got any other ideas?

Should we provide an API for clicking on parts of the canvas? or should this be a separate driver?

From Gitter (source):

I'd like to create a small drawing app with Cycle and create a canvas like this as a VDOM. I'd like to use cycle-canvas, but it looks like I need to create a canvas beforehand or let cycle-canvas create on for me, but then I don't have full control of it. I guess I'd need a way to add the canvas element to the sink in order to create a canvas dynamically...? (And is there a better way to get the element as an observable than this?)

Hi! I am looking into a cycle.js solution for canvas. However, this package indicates being highly experimental and hasn't been updated for years. Has someone collected experience with it on production or is there another solution out there? If not, do you think that this indicates that cycle.js/RFP isn't appropriate for working with canvas and what better approaches/paradigms do you suggest? I really like cycle.js's mental model and would like to know the reason of its lack of adoption when working with html canvas. Any advices?

Thank you!

line({x: 0, y: 0, x2: 50, y2: 50}) or something?

Here is a list of what I think we need to do to release v0.1.0:

package.json

• Replace all instances of "cycle-hot-reloading-example" with "cycle-canvas"
• Set version to v0.1.0
• Everything in dependencies should be in devDependencies. (we don't actually use any of it in the driver, just examples)
• Add some scripts to compile our es6 to es5 prior to release. These will hook into the npm publish step

   "scripts": {
     "start": "babel-node ./examples/flappy-bird/server.js",
     "test": "mocha --compilers js:babel-register",
     "bundle": "browserify ./examples/flappy-bird/index.js -t babelify -t uglifyify -o bundle.js",
+    "precompile-lib": "rm -rf lib/ && mkdir -p lib",
+    "compile-lib": "babel src -d lib",
+    "prepublish": "npm run compile-lib"
   },

• Change the main file to point at the compiled es5 code (src/canvas-driver.js -> lib/canvas-driver.js)
• Add a files array with lib/ so that it gets included in the compiled package

+   "files": [
+     "lib/"
+   ],

After all that is done we need to test that the module can be installed locally.

• Run npm link in the cycle-canvas directory
• Copy one of the example projects to a directory outside the cycle-canvas directory
• Run npm link cycle-canvas in the copied example directory
• If you ls node_modules/cycle-canvas, you should see the cycle-canvas code, including the lib directory
• Change the example to import from cycle-canvas instead of the relative path.
• You should be able to run the example and it should import cycle-canvas successfully

After we've tested that we can install our module locally we're almost ready for release.

• Push all changes up and check that travis passes
• git tag v0.1.0
• git push origin master --tags
• npm adduser (you should only have to do this the first time and you'll need an npm account)
• npm publish (exciting!)
• try npm install cycle-canvas in the copied example project
• celebrate! 🎉
• tell the world!

I think that's everything, but there's a good chance I've missed something. Give it a go and let me know how you get on!

Means porting to xstream ideally, we can look at the http driver as an example.

Finally getting back on the bandwagon here, I was all rearing to write some code. However, I realized that while in most of my recent endeavors I've been using ESLint for hints and consistency, this is not the sort of thing I feel comfortable subjecting the project to without consulting others.

So, how do we feel about ESLint? Would it be all right to incorporate it as a development dependency?

I feel a bit guilty about having this under my username when really the hard work is being done by you awesome contributors.

Is it okay if I move this repo into the new cyclejs-community org? https://github.com/cyclejs-community

I think that would better reflect who the true authors are.

@apretto @schempy @edwin-nz

Before we release v0.1 it would be great to add some documentation to the README around the various options that are currently available.

@schempy @apretto do either of you feel like taking a crack at this? I probably won't get to it this week (currently traveling, will only be home for a day before I have more traveling to do). I'm more than happy to help though.

I think this is the last thing we need to do before our first release.

What element hierarchy is meant to represent?

In other words, how

rect({children: [
  rect({
    x: 10, y: 10, width: 160, height: 100,
    children: [
      text({x: 15, y: 25, ...})
    ]
  })
]})

is different from

rect({children: [
  rect({
    x: 10, y: 10, width: 160, height: 100,
  })
  text({x: 15, y: 25, ...})
]})

In DOM tree there is a particular meaning of node hierarchies described by "block model".
What it represents here?

1. Some overlay rules?
2. Grouping for transformations?
3. User-level classification stuff?
4. Nothing but reserved for future?

Specifically translation, rotate and scale: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Transformations

How does one go about publishing new versions of this package to NPM? Only @schempy appears to have the appropriate credentials.

I propose to add the polygon function to the driver:

• given a list of points, draw a closed polygon (either filled, stroked or both). See https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Drawing_shapes#Drawing_a_triangle

I'll start an implementation for it, but any input is welcome.

The signature I'm considering will look something like this:

polygon({
  transformations: [],
  points: [{x: 10, y: 10}, {x: 20, y: 10}, {x: 15, y: 17}],
  draw: [
    {fill: 'purple'}
  ]
}); // draw a purple triangle

Also, perhaps we should consider removing the x and y parameter from the line function, and have that point being the first one in the list of points, just like I propose here in the polygon.

Thoughts on this last idea?