Closed lesion closed 6 years ago
Hi,
yes I considered this, but I'm still not sure about the best way to do it.
I will put some more thought in it and I would be very happy to get more information about how others are using the lib, so I can make the best decision for the lib.
Hey, I'm actually trying to integrate ffwdme with OSRM: this would mean changing some minimum stuff (OSRM use 6 digit precision on polyline encoding instead of 5 of Google Maps, like so) and implementing a new Routing class for OSRM service. I think this should be easy to do (also because your code is pretty clean :) , I'll try to keep the quality high so maybe you'll merge) ciao
Hey, this sounds pretty cool! Once you are happy with your OSRM integration, feel free to open a pull request!
Oh - and let me know, if there is something I can help with.
I gave the npm topic some thought. At the moment I think it would be a good idea to split the code base into three different packages: core
, components
and debug
.
I don't want to complicate things by splitting it up into too many packages, but I think this separation would be reasonable, because I guess most people don't want to use the debug libs in production and probably will also use their own UI components.
But before I do this, I would love to hear some thoughts by other users of the lib, because I don't want to break other peoples workflow.
Closing this for now
If I may, most people using npm on client side use a bundling solution. One way could be to build everything in a /build or /bundle folder. Have the core bundle be the main entry, so you can do require('ffwdme'). And then have the others named debug.js and components.js, so you can do require('ffwdme/debug') and require('ffwdme/components').
What do you think ? I could give you a PR on that. I'm not familiar with browserify, but I believe we just need to change the last lines in that gulp file : https://github.com/ffwdme/ffwdme.js/blob/master/gulp/tasks/browserify.js. Add a /build, start the bundle task on npm publish, setup the package.json, add a .npmignore and we're set !
Hey, thank you for the offer, I thought about this too, but never did it because I didn't get feedback. But before we start, I need to make up my mind, how I want to modernize the lib in general, so it is a little bit early for a PR :)
Maybe we could reopen this issue so that it's more apparent to people coming that may have an opinion to give.
I'm not sure what you mean with modernizing, if you mean moving to es6, since the library is mostly built around classes, or simply the way it's packaged.
Here is my experience. I cloned the library. Removed the proxy part since I use it in a react-native project and have no DOM. I use the global ffwdme object attached in the index.js. Things I would consider:
Thank you for sharing your experience, this is incredible valuable for me!
I would like to modernize the lib in general at some point (build process, more ES6 features etc).
Removing the ffwdme global namespace would require for some new APIs and maybe an extra version of compatibility, but I think this should be the future direction.
I only use webpack in current projects so this is for me the way to go too.
Just to let you know, I'm busy on other things at the moment, but I'm pretty interested in helping you if you wish to do the migration, maybe one way to get started is to create an upgrade branch and start setting up some webpack already.
I would see it in two steps, first getting webpack to do the build, and then starting the rewrite. What do you think ?
Yes, I agree that this is the right approach!
@lesion Did you manage to integrate ffwdme with OSRM ? Ideally, I would like to use ffwdme with OSRM and openstreetmap. Is that possible at all ? Thanks
Closed due to inactivity.
Hi, are you going to publish an npm or bower package of this library ? This would be great ! Thanks for this toolkit!