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.

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

More modular design #11

Closed
justsml opened this issue Feb 24, 2015 · 5 comments
Closed

More modular design #11

justsml opened this issue Feb 24, 2015 · 5 comments

Comments

@justsml
Copy link
Contributor

justsml commented Feb 24, 2015

I was trying to figure out the best way to make the code more modular/monad-like.
So, for example let's consider the path splitting features as chain-able modules: dottedPaths, arrayPaths, functionPaths, or something like customPathMapper

This would make it easier to exclude, say, function-path features (XS exploits come to mind), not to mention it'd be easier to make custom keypather builds. Like a light-weight read-only path checker for the browser would be really handy, especially on mobile.

Anyway, I was just wondering what @tjmehta thoughts are on this.

Thanks for the awesome lib!

// mock example:
var getPath = require('keypather/get'); // note: get.js could be used by browserify to get only the dependencies required for reading objects
console.log('Email: ', getPath(user, 'contactInfo.email');
@tjmehta
Copy link
Owner

tjmehta commented Feb 25, 2015

Quick thoughts: I like this idea a lot (splitting each operation into it's own module/file)

@stoeffel
Copy link

👍

I think #10 could be solved with this one too.

@justsml
Copy link
Contributor Author

justsml commented Feb 26, 2015

Hey @tjmehta ... In trying to decompose the index.js and it's methods, I've made the code a little uglier I feel. (I'll reference my branch when I load it... )

Let me explain where I'm at: I love seeing solid use of prototype like this, however I'm currently breaking it up into more basic utility-function design ( sub-classes and prototype might be overkill for this. Ultimately I think a skinny+modular design will come from using a direct require('./lib/xyz') design - accessing state-less/instance-less feature methods). So index.js would look like a little like this: exports.get = require('./lib/get') this would make it 'instance-free' and each call's lifetime is clearly scoped: run's in it's own closure, allowing better garbage collection

Current progress/thoughts

  1. I've been re-factoring the getValue fn and it's dependent method chain,
    1. Moved fns: handleKey, handleFunction, handleBrackets under getValue
  2. Can in() and has() be updated to use get() directly?

@justsml
Copy link
Contributor Author

justsml commented Feb 26, 2015

Other thoughts

In order to design (what I think is) an ideal plugin model, I usually assume an infinite possible # of plugins... While this is probably not a likely requirement for a module with most functionality included - hopefully this will just make code more tightly scoped)
I typically design a plugin interface with members like: run(obj), int priority (maybe a hasRun(obj) et al.)
For keypather, I think a plugin interface method like canRun(keyPath) or isNeeded(keyPath) would cleanly separate the main class out, so it's just a coordinator/controller simply running 'steps'

This should also allow for more isomorphic usage patterns - perhaps like this:

var basicGet = Keypather.run.bind([require('./plugins/dottedPaths'), require('./plugins/expandPath')])
var getArray = Keypather.run.bind([require('./plugins/dottedPaths'), require('./plugins/arrayPaths'), require('./plugins/expandPath')])

@tjmehta
Copy link
Owner

tjmehta commented Jan 14, 2018

published keypather@v3.0.0 !

@tjmehta tjmehta closed this as completed Jan 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants