search

Raynos / mercury

A truly modular frontend framework
http://raynos.github.io/mercury/
MIT License
2.82k stars 143 forks source link

Export virtual-hyperscript/svg #181

Closed crabmusket closed 9 years ago

crabmusket commented 9 years ago

Because why not?

danielnaab commented 9 years ago

Byte counting.

crabmusket commented 9 years ago

Not sure if serious. I think having SVG available is pretty important. I've been bitten before by trying to require virtual-hyperscript myself and then running into a version mismatch.

DeepAnchor commented 9 years ago

IMO it doesn't belong in core. To me, the core should be the minimal subset of modules an app needs to get up and running -leave the rest for the user to require manually.

crabmusket commented 9 years ago

This is the only real alternative I've found:

var svg = require('mercury/node_modules/virtual-dom/virtual-hyperscript/svg');

Or watching the version of virtual-dom in mercury and keeping a separately installed copy of virtual-dom up to date, which I didn't want to have to do.

I definitely understand the rationale behind a small core, but taken to the logical extreme none of the state modules would belong in it. I feel this addition is acceptable in the spirit of the other things that are in the core.

Raynos commented 9 years ago

@eightyeight it was removed to keep a small core.

If your using mercury in production I recommend you just copy mercury/index.js into your app and pull in all the dependencies one for one.

This allows you to customize it to your need; like adding svg.

crabmusket commented 9 years ago

@Raynos: meet you in the middle: can we export SVG as h.svg? That would be a change in virtual-dom/virtual-hyperscript, not in this repo, but what do you think of the idea?

kumavis commented 9 years ago

@eightyeight why dont you just import it yourself? why does it need to be a part of those modules?

var svg = require('virtual-dom/virtual-hyperscript/svg');
crabmusket commented 9 years ago

Because that requires that I depend on virtual-dom directly, and that I therefore have to keep the version up to date with the version mercury uses. You know, it's not the end of the world, but I thought exporting SVG from mercury wouldn't be the end of the world either haha.

kumavis commented 9 years ago

@eightyeight I do reccomend taking @Raynos's suggestion of making a mercury.js file from mercury's index.js and sort of subsuming this repo into your front end. maybe mercury would be better as a yeoman template? hmm people have strong feelings about yeoman

Raynos commented 9 years ago

We can add a top level svg.js so you can do require('mercury/svg')

crabmusket commented 9 years ago

@Raynos that works for me, if you're happy with it! @kumavis I guess that does make some sense.