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

[Change] Simplify module data #73

Open
wants to merge 63 commits into
base: develop
Choose a base branch
from
Open

[Change] Simplify module data #73

wants to merge 63 commits into from

Conversation

backflip
Copy link
Collaborator

As suggested by @marbor3 about 25 years ago, we should probably simplify our data files.

backflip and others added 30 commits September 16, 2018 00:09
[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
* [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
data,
template,
handlebars,
skipCode: true,
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This optional boolean allows us to skip the whole Code block (i.e. for modules like media where the whole markup is only for demo purposes).

Without this, we are rendering the following:
image

return this.getHighlightedTemplate(content);
},

getFormattedHandlebarsPartials(content) {
Copy link
Collaborator Author

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;
Copy link
Collaborator Author

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) {
Copy link
Collaborator Author

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) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extracted helper method

@marbor3
Copy link

marbor3 commented Oct 11, 2018

A general comment. I had a look into it in current project, based on old Estatico, but still, this is still valid for nou one.

What we wanted to achieve:

  1. Remove boilerplate and simplify code for creating module meta
  2. Create a simple and readable way of creating variants
  3. If possible create module data examples only on that modules data.js files

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. data here is the data for default module variant.

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 data.js file for a module with default variant only.

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 data sets for module are created using addData in the module where it belongs, and then in modules that would want to inject another module we import this data only:

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 :)

@CLAassistant
Copy link

CLAassistant commented Jul 30, 2019

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 3 committers have signed the CLA.

✅ orioltf
✅ backflip
❌ Christian Sany


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.

@marbor3
Copy link

marbor3 commented Jan 17, 2022

Cleaning up my to review list and ... hmm, it's been a while since I've been here. Shall we merge? :p

@backflip
Copy link
Collaborator Author

@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.

@marbor3
Copy link

marbor3 commented Jan 17, 2022

agreed

Copy link

@marbor3 marbor3 left a 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

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

Successfully merging this pull request may close these issues.

None yet

4 participants