garyb / purescript-virtual-dom

Low level virtual-dom bindings for PureScript
MIT License
30 stars 7 forks source link

How do I build this? #10

Open AKST opened 9 years ago

AKST commented 9 years ago

I'm new to purescript in general, but unsure how I'm suppose to build this as I got the following error in the JS console when I built this.

Uncaught ReferenceError: require is not defined

Which happens here

PS.VirtualDOM_VTree = (function () {
   ...
  var vnode$prime = (function() {
    var VNode = require('virtual-dom/vnode/vnode');

    return ...;
  }());
  ;

I'm guessing I'm suppose to use browserify with this (or something along those lines)? Anyways how do I build this for client side code? I haven't seen anywhere online how you'd use purescript with browserify, I've seen pulp, but I rather avoid learning another new tool just to get this to build (along with restructing my project), if I can...

Alternatively would it worth considering inlining a reference the appropriate parts of virtualDom if the require function is not present?

edit: spelling & additional details

garyb commented 9 years ago

What are you using to build the project currently? If you're using gulp or grunt you can integrate a browserify step into the project the "usual" way there (example gruntfile using browserify here).

If you're not, then I really would recommend taking another look at pulp, it is by far the simplest way of building PureScript projects at the moment. You'd basically just npm install virtual-dom then run pulp browserify and that should be it. The purpose of pulp is to eliminate as much explicit build stuff as possible with the tradeoff being having to stick to a few conventions.

When we started with this virtual-dom was only available as a collection of CommonJS modules, so there was no option but using browserify, but it seems there is now a pre-browserified JS available, however I think I'd prefer to keep the FFI code using require as it is more the "right" way to do it than assuming the virtual-dom stuff is available globally somehow.

AKST commented 9 years ago

Yeah, that's fair enough. I'm using gulp at the moment so those examples should be helpful, if I can't get them to work for me, I'll nuke everything and try pulp. Thanks (edit: ok I just looked at the example, I can't believe I didn't do something like this earlier...)

To avoid future confusion for other new users, could it be worth while demonstrating this build process in the examples, or a mention in a faq in the readme? From my first 24 hours with purescript, this was the only client side library I've used that I encounter this.

Idk, maybe it's just me ¯(ツ)

edit: clarity

On Sun, 1 Mar 2015 at 12:27 am, Gary Burgess notifications@github.com wrote:

What are you using to build the project currently? If you're using gulp or grunt you can integrate a browserify step into the project the "usual" way there (example gruntfile using browserify here https://github.com/paf31/purescript-croco/blob/gh-pages/Gruntfile.js).

If you're not, then I really would recommend taking another look at pulp, it is by far the simplest way of building PureScript projects at the moment. You'd basically just npm install virtual-dom then run pulp browserify and that should be it. The purpose of pulp is to eliminate as much explicit build stuff as possible with the tradeoff being having to stick to a few conventions.

When we started with this virtual-dom was only available as a collection of CommonJS modules, so there was no option but using browserify, but it seems there is now a pre-browserified JS https://github.com/Matt-Esch/virtual-dom/tree/master/dist available, however I think I'd prefer to keep the FFI code using require as it is more the "right" way to do it than assuming the virtual-dom stuff is available globally somehow.

— Reply to this email directly or view it on GitHub https://github.com/purescript-contrib/purescript-virtual-dom/issues/10#issuecomment-76528046 .

garyb commented 9 years ago

No you're absolutely right, and actually I'm surprised you've not run into problems with other libraries yet. I think generally we have a "getting started" problem in PS at the moment - once you figure things out it's fine, but the initial hurdle is pretty high.

There's some discussion about it here: purescript/purescript#749 I don't think we've made any real progress on it yet, but if you have any input or ideas about things that would have helped it'd be appreciated.

AKST commented 9 years ago

Sure thing, I'll recap my initial experience & any hurdles I've had so far getting started. I won't get around to it till the next morning though, as it's late here.

garyb commented 9 years ago

Thanks!

alexchandel commented 9 years ago

The Readme should mention that this has a non-Bower build dependency.

The most "right" way would probably be to implement a virtual DOM directly in PureScript, thus exposing it to PS optimizations.

arianvp commented 9 years ago

@alexchandel This shouldn' actually be too hard I think. Just wondering how you would do the 'reference equality' optimizations. Equalities in purescript are "deep" right? If you have a tree it traverses the whole tree.. it doesn't do reference equality checks? correct me if I'm wrong

garyb commented 9 years ago

It depends on the Eq instance for the type :) But yeah, that will be "deep" equality.