Add flowconfig to SampleApp #815
Conversation
facebook-github-bot
added
the
CLA Signed
frantic
force-pushed
the
sample-app-test
branch
from
e8db1b7 to
9b513ed
Compare
frantic
changed the title
|
@bhosmer - does |
|
@frantic LGTM - passes w/0 errors, right? |
|
On Flow's side would it be possible to transitively include .flowconfigs of [include]'d directories and require()'d npm packages? It would let projects customize their .flowconfig files while keeping an up-to-date reference to React Native's .flowconfig and other projects' .flowconfig files if Flow gains more adoption. I opened an issue over at facebook/flow#308 if that's a better place to make progress. |
|
@ide James, note that such an include wouldn't come in handy here - the project has its own copy of everything, it's not reaching back to the original React Native dir. That said, we've talked about some sort of include feature, but it would be more a way to include raw content than a deep "subproject" sort of feature, at least for now. Will update 308 with any progress. |
Yeah. It would be nice if individual projects could each import one React Native .flowconfig into each of their own .flowconfig files. |
Summary: Fixes #815 Imagine a node with this style: `{ paddingHorizontal: 10, paddingStart: 0 }`. After running layout on this node, we expect its computed `paddingStart` to be `0`. However, it is actually `10`. Consider the expression `paddingEdgeStart.getValue() > 0.0f` in [`getLeadingPadding`](https://github.com/facebook/yoga/blob/328ec7dc4d104b42b836d5ccebff04033d045133/yoga/YGNode.cpp#L461). Why is `0` handled like a negative number rather than a positive number? I suspect this should be `>=` so `0` is handled like the positive numbers (this is how `getTrailingPadding` works). It looks like facebook/yoga@3a82d2b?diff=unified&w=1#diff-07b4949bf42749fde386e769ff08a124 changed the operator from `>=` to `>` in `getLeadingPadding`. I suspect it was a mistake. `getTrailingPadding` still uses `>=`. I manually verified this using the code in #815 and added some unit tests to catch this bug and other similar issues. Adam Comella Microsoft Corp. Pull Request resolved: facebook/yoga#816 Reviewed By: priteshrnandgaonkar Differential Revision: D10282617 Pulled By: shergin fbshipit-source-id: 2ab2874ae39d9454308a020a960ace85573fe777
Summary: Fixes #815 Imagine a node with this style: `{ paddingHorizontal: 10, paddingStart: 0 }`. After running layout on this node, we expect its computed `paddingStart` to be `0`. However, it is actually `10`. Consider the expression `paddingEdgeStart.getValue() > 0.0f` in [`getLeadingPadding`](https://github.com/facebook/yoga/blob/328ec7dc4d104b42b836d5ccebff04033d045133/yoga/YGNode.cpp#L461). Why is `0` handled like a negative number rather than a positive number? I suspect this should be `>=` so `0` is handled like the positive numbers (this is how `getTrailingPadding` works). It looks like facebook/yoga@3a82d2b?diff=unified&w=1#diff-07b4949bf42749fde386e769ff08a124 changed the operator from `>=` to `>` in `getLeadingPadding`. I suspect it was a mistake. `getTrailingPadding` still uses `>=`. I manually verified this using the code in #815 and added some unit tests to catch this bug and other similar issues. Adam Comella Microsoft Corp. Pull Request resolved: facebook/yoga#816 Reviewed By: priteshrnandgaonkar Differential Revision: D10282617 Pulled By: shergin fbshipit-source-id: 2ab2874ae39d9454308a020a960ace85573fe777
Added
.flowconfigtemplate (and a test for it!)Test Plan: