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.

Sign up for GitHub

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

Jump to bottom

incorporate browserify? #8

Closed
mapsam opened this issue Mar 23, 2015 · 4 comments · Fixed by #132
Closed

incorporate browserify? #8

mapsam opened this issue Mar 23, 2015 · 4 comments · Fixed by #132
Labels
question

Comments

@mapsam
Copy link
Member

mapsam commented Mar 23, 2015

@thebigspoon I'm curious if you'd want to use browserify here or stick with using the Grunt wiredep for loading in all of our bower components?
@mapsam mapsam mentioned this issue Apr 1, 2015
Merged
@mapsam
Copy link
Member Author

mapsam commented Apr 2, 2015

After #19 we are removing bower from the equation and going to roll with some quick CDNs and begin working on incorporating browserify for module use.

@mapsam mapsam mentioned this issue Apr 2, 2015
Open
@ranchodeluxe ranchodeluxe mentioned this issue Apr 3, 2015
Closed
ranchodeluxe added a commit that referenced this issue Apr 4, 2015
@ranchodeluxe
start dron-n-chop rewrite as Leaflet subclasses
cdf4334 
this is an example that takes an existing drop-n-chop "component"
and creates a DropZone Leaflet subclass with a FileReader
handle which delegates events for the map's drag-n-drop options.

I think it would be nice if the other drop-n-chop "components" were
also written as Leaflet extensions/subclasses.

For example:

- The FileLayerList could extend L.Control.Layers as this extensions
does >
https://github.com/stefanocudini/leaflet-panel-layers/blob/master/src/leaflet-panel-layers.js

- The GeoMenu could extend L.Control to create the dropdown toolbar

There would still be a drop-n-chop module that wraps the mapping needs
and also has refs to the above components as this commit shows with
L.DNC.DropZone.FileReader

regarding discussion in #8, we then don't need browserify at all.
regarding issues ( #22, #23 ), tests will be easier to write
when we come to an agreement on the structure
@mapsam mapsam closed this as completed May 7, 2015
@mapsam mapsam reopened this May 13, 2015
@mapsam
Copy link
Member Author

mapsam commented May 13, 2015

This is coming up as an issue as people begin looking at #11 and making @aaronr angry!

@mapsam mapsam mentioned this issue May 14, 2015
Closed
@alukach
Copy link
Member

alukach commented May 14, 2015

What does @aaronr think about this?

Why was it that we decided to table browserify in the first place? I don't quite recall. I do like the idea of writing this all node-like in the event that we ever want to make an offline-friendly downloadable DNC.

@ranchodeluxe
Copy link
Member

@svmatthews @alukach @aaronr
I think the easiest solution is to only use browserify to require the third-party modules we need and then expose/tag them to the L.DNC namespace. You'll just have to ensure that the browserify build happens at the end of the L.DNC build so the L.DNC namespace is already available.

var shape_package = require('shapefile-lib-thing');

L.DNC.ShapeUtils = shape_package;

mapsam added a commit that referenced this issue Jun 3, 2015
@mapsam
use grunt-browserify, #8
ab2fd16
@mapsam mapsam mentioned this issue Jun 3, 2015
Merged
mapsam added a commit that referenced this issue Jun 3, 2015
@mapsam
recursive rename, update browserify usage #8
52e0ccd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Incorporate browserify cugos/dropchop
3 participants
@ranchodeluxe @alukach @mapsam