Conversation
Running into nondeterministic test failures with the PhantomJS + |
Changes Unknown when pulling 6e29cbe on feature-initial-api into * on master*. |
- Create build tool to pre-calculate initial layouts. | ||
- Decide on a distribution strategy for the WebWorker code (preference on inlining). | ||
- Decide on an animation strategy (requires support for removing constraints). | ||
- Allow for self-referential subviews in the constraint props array without using the subview string. |
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.
This README is 💯 - usage section, especially. One question, however: will the DSL be documented?
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.
Yes indeed! I'm debating on docstrings vs. just writing it out, thoughts?
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.
If it were just for me, I'd vote for docstrings - I like reading through the source. But since this is a public package, I guess explicit documentation in the README would be better.
@tptee this is looking great! Can you add a todo for an initial render strategy for when layouts aren't pre-calculated? |
@boygirl Sure thing! |
}; | ||
|
||
export default Object.keys(transformers).reduce((acc, key) => { | ||
return {...acc, [key]: Subview(key, transformers[key])}; |
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.
GLOBAL: Mutate instead of extending where possible.
This:
export default Object.keys(transformers).reduce((acc, key) => {
return {...acc, [key]: Subview(key, transformers[key])};
}, {});
translates to:
"use strict";
Object.defineProperty(exports, "__esModule", {
value: true
});
var _extends = Object.assign || function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; };
function _defineProperty(obj, key, value) { if (key in obj) { Object.defineProperty(obj, key, { value: value, enumerable: true, configurable: true, writable: true }); } else { obj[key] = value; } return obj; }
exports.default = Object.keys(transformers).reduce(function (acc, key) {
return _extends({}, acc, _defineProperty({}, key, Subview(key, transformers[key])));
}, {});
which is a lot of object extending / re-recreation.
Instead, doing a shallow straight mutation like:
export default Object.keys(transformers).reduce((acc, key) => {
acc[key] = Subview(key, transformers[key]);
return acc;
}, {});
translates to:
"use strict";
Object.defineProperty(exports, "__esModule", {
value: true
});
exports.default = Object.keys(transformers).reduce(function (acc, key) {
acc[key] = Subview(key, transformers[key]);
return acc;
}, {});
and notably avoids all the object re-creation / extending...
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.
👍 . Less "tricky" and more readable as well
Changes Unknown when pulling 4caab16 on feature-initial-api into * on master*. |
Changes Unknown when pulling 4caab16 on feature-initial-api into * on master*. |
…pack TODO since there's now an issue for it
Changes Unknown when pulling 0778a55 on feature-initial-api into * on master*. |
Changes Unknown when pulling 0778a55 on feature-initial-api into * on master*. |
Thanks for your help, everyone! I've integrated your suggestions and ticketed out future work/enhancements. I'm going to merge this so that we can start reviewing smaller PRs 😜 |
Changes Unknown when pulling 445aedf on feature-initial-api into * on master*. |
The initial implementation of
radium-constraints
should be a good enough kickstart to begin integration intovictory
. This library came to life as a solution for multiple layout problems in victory:FormidableLabs/victory-core/issues/17
FormidableLabs/victory-chart/issues/122
FormidableLabs/victory-chart/issues/124
FormidableLabs/victory-chart/issues/121
FormidableLabs/victory-chart/issues/33
You can track integration with Victory here:
FormidableLabs/victory/issues/225
From the README:
Learn more about constraint-based layouts:
http://overconstrained.io/
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/
https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf
https://gridstylesheets.org/