-
Notifications
You must be signed in to change notification settings - Fork 6
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
[Change] Simplify module data #73
base: develop
Are you sure you want to change the base?
Conversation
[Chore] Fixed failing tests
…#61) * [Chore] estatico-boilerplate: Optimized global client-side namespace * [Chore] estatico-boilerplate: Changed module class name
…ing in boilerplate, refactored styles accordingly
Enable Stylelint
* [Change] estatico-boilerplate: Removed jQuery * [Chore] estatico-qunit/estatico-svgsprite: Rewrote client-side code to remove ES2015 features * [Fix] estatico-boilerplate: Added missing polyfills for IE11 * [Change] estatico-eslint: Added default config, added babel-eslint as parser
… estatico-stylelint config accordingly
estatico-json-schema: Added task to validate input data against JSON schema
[Update] estatico-font-datauri: Added rename option
Add .editorconfig to boilerplate
Update async polyfill loading and add unified package for polyfills
…ing module data files
data, | ||
template, | ||
handlebars, | ||
skipCode: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return this.getHighlightedTemplate(content); | ||
}, | ||
|
||
getFormattedHandlebarsPartials(content) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Separated into two methods in order to call both in a lazy way (only when rendering the template but not when requiring the data file).
@@ -133,7 +130,7 @@ module.exports = { | |||
*/ | |||
getUsedPartialsInTemplate(content) { | |||
let list = []; | |||
const regexp = /{{>[\s"]*([a-z0-9/_-]+\/_[a-z0-9/._-]+)[\s"}]/g; | |||
const regexp = /{{>[\s-]*["|']?([^"\s(]+).*?}}/g; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copied simplified version from the dependency graph
@@ -170,14 +167,6 @@ module.exports = { | |||
return marked(content); | |||
}, | |||
|
|||
getMarkedHandlebars(filePath, context) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently unused
/** | ||
* Set up variant data to be rendered with code preview etc. | ||
*/ | ||
setupVariants(config) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extracted helper method
A general comment. I had a look into it in current project, based on What we wanted to achieve:
We started by creating a ModuleMeta wrapper, so creating meta data for module looked like: new ModuleMeta({
moduleName: 'teaser',
jira: 'jira-180',
title: 'Teaser'
}, {
data: data
}); hbs, md files, some keys need to follow naming convention so it's the same and in the same folder and has the same file name as module but for simplicity I can give up option to have this as a variable. And that's it, to create the most simple module you need: const ModuleMeta = require('../../../helpers/modulemeta.js');
module.exports = new ModuleMeta({
moduleName: 'teaser',
jira: 'jira-180',
title: 'Teaser'
}, {
data: {
title: 'my title'
}
}); And that’s your whole To simply add another variant there’s another simple helper: moduleMetaInstance.addVariant('variantKey', 'New Variant', { title: 'second variant' }); Each variant creates a data object that can be reused in other places like this: moduleMetaInstance.getData('variantKey'); // { title: 'second variant' } And just on additional method, creating data without creating a variant that shows on preview: moduleMetaInstance.addData('third', { title: 'hurray!' }); So it can be used: moduleMetaInstance.getData('third'); // { title: 'hurray!' } We try to work in a way that const heroImage = require('../image/image.data.js').getData('hero'); Project has this setup since about 6 months, over 50 modules created, so far it’s pretty easy to use, we’re quite happy, downsides - since we try the data to be logic less it’s sometimes a lot of duplicates, we tried with additional helper methods, still have a bunch, code is cleaner but way less readable, you really need to know your tools to code and debug fast, there’s also larger learning curve, so in the end we voted for simplicity and just like two methods mostly :) |
Christian Sany seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
Cleaning up my to review list and ... hmm, it's been a while since I've been here. Shall we merge? :p |
@marbor3, I would close it. New projects should use de-facto standardized tooling like Storybook anyway and I don't think anyone should spend time updating data files in an existing project but rather migrate it to a new setup instead. |
agreed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's a real shame, but it's outdated :( to be closed
As suggested by @marbor3 about 25 years ago, we should probably simplify our data files.