-
Notifications
You must be signed in to change notification settings - Fork 22
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
proposed refactor of data handling #45
Comments
Why not just save it at I mean, we already have access to the very base instance from plugins/generators.
We have What about app.use(function (app, base) {})
If you choose |
That's what we're doing currently, this was always my preference. I'll try to see if I can figure out why it's not working in some situations. We might be able to solve this issue simply by enforcing a convention for how data is cached after an answer is given. actually... I might be able to do something with enquirer to make this easier without adding magic. after I play around with that I'll report back |
This is related to the
data
bullet in #35.For the first time in all of my node.js projects, globals are looking like the most appropriate solution. Given that generators are run via command line to scaffold out a new project, versus running a server for a live application or something. In a single session, generate can chain generators and, ideally (and optionally), prevent the same prompt from being presented multiple times by:
We've tried a few solutions to make sure the data from prompts is always available to all generators, but it hasn't been easy - especially since the code is written to ensure that generators have their own instance (and do not share state). The need for a session answer-cache that is available to all generators consistently seems like as good of a use case for globals as we're likely ever going to have.
Assuming others don't find this completely distasteful, here is how I propose we do it:
global
, likeSOME_LONG_ANSWER_CACHE_NAME
app.global.set()
,app.global.get()
etc. These would of course also support object paths, likeapp.global.get('foo.bar.baz')
. We could also have a.merge()
method or something, so that data from generators could be stored separately until it's needed, at which time it would be cloned and merged.I'm open to any alternatives, opinions, suggestions or pushback...
Any thoughts @doowb @stefanwalther @tunnckoCore @dawsonbotsford or others?
The text was updated successfully, but these errors were encountered: