Open jaydson opened 9 years ago
Very nice start! :+1:
We could focus on the API, then the CLI would just have to call API functions behind the scenes. This way we don't duplicate code and it eases keeping feature parity betwen API and CLI.
Other things we should clean up:
sitePath
around: currently, most if not all functions in parser.js
receives sitePath
as argument (this is kind of a hack I implemented to fix tests/allow more flexibility). We could transform parser.js
into a central harmonic.js
which exposes a Harmonic class -- e.g. it could be the main API endpoint which takes sitePath
as a constructor argument and stores it into a "private" property (undocumented, with a leading or trailing underscore). Of course, most of the current parser.js
file can be broken down into smaller pieces and placed in the core_modules dir.Misc:
core_modules
to lib
? This is the convention I'm used to see, but I guess this doesn't matter much.Really cool.
I believe it would also be cool to have some hooks, like "before building", or for each generated file. For instance, I would want to get a list of videos from a feed(from my youtube channel) to bind onto a template.
Great insights here. Thanks both @UltCombo and @felipenmoura.
We can change the core_modules
folder name, it was just an example.
@felipenmoura I believe that fits in https://github.com/es6rocks/harmonic/issues/6
@jaydson I think we should do this in small (but "complete") steps. E.g.:
We can change the core_modules folder name, it was just an example.
I don't really care about the name either, it was just a random idea. :stuck_out_tongue:
Can we focus on this refactoring soon? I guess it would be nice to get this done as soon as we merge the currently open big PRs/branches (ESLint, external themes).
@jaydson can we schedule a hangout to kick off this refactoring?
It's time to apply some serious code refactoring on Harmonic. The project has evolved and we discovered a lot of quirks in tools we're using and within our own code. As a bleeding-edge project, this kind of thing can happen at any time, and this is awesome IMHO.
I'm labelling this issue with 'discussion' and 'p2' because we need to define some goals first, but after that, refactoring is absolutely one of ours priorities.
I'm starting to draft a model(kind of) of what we can do in our code structure, based on what we already have:
What we have in this first draft:
./bin
folder cleanupcli
,config
,resources
folders. The idea here is to isolate specific code inside those foldersskeleton
andclient
folders moved toresources
foldercore_modules
*core_modules folder: All internal modules must to be placed inside the
core_modules
folder. We can split the code in tiny modules, so we can re-use in CLI, API, etc. Another benefit of thecore_modules
folder is that we can identify future node modules, so we can "promote" them to npm.I definitely need some help and feedback here @UltCombo @leobalter @felipenmoura