-
Notifications
You must be signed in to change notification settings - Fork 22
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
Needles should be recursively resolved #55
Comments
Hi @jtmthf. I'm not sure if I got it. export const contrastText = (bgNeedle: Needle<any>) =>
withProp(
[bgNeedle, p('black'), p('white')] as any,
(bg: string, black: string, white: string) => {
// bg ends up being a prop getter function here instead of a string.
return getLuminance(bg) > 0.179 ? black : white;
},
); Are If you could create some failing tests, I think it would be easier to understand. Either way, I agree with your title |
@diegohaz already on a PR! In order to be consistent, I think that any function that resolves a prop-getter should deeply resolve the value. As of now, I'm working on test("deep function argument", () => {
expect(ifProp(() => props => props.foo, "yes", "no")()).toBe("no");
expect(ifProp(() => props => props.foo, "yes", "no")({ foo: false })).toBe(
"no"
);
expect(ifProp(() => props => props.foo, "yes", "no")({ foo: true })).toBe(
"yes"
);
});
test("deep function values", () => {
expect(
ifProp("foo", () => props => props.foo, () => props => props.bar)({
bar: "bar"
})
).toBe("bar");
expect(
ifProp("foo", () => props => props.foo, () => props => props.bar)({
foo: "foo"
})
).toBe("foo");
});
test("deep function array argument", () => {
expect(
ifProp([() => props => props.foo], "yes", "no")({ bar: false, foo: true })
).toBe("yes");
expect(
ifProp(["bar", () => props => props.foo], "yes", () => "no")({
bar: false,
foo: true
})
).toBe("no");
}); |
I thought more about the "deep function values" test case as it may not be needed with styled-components. Assuming the result of |
Reopening as we need to figure out a better solution (the other one introduced breaking changes #57). |
I think it makes sense that In the case that someone does want |
What about a deep version of withProp(deepProp(props => props => props.foo), x => x);
ifProp(deepProp(props => props => props.foo), true, false);
... |
That might be more clear. As Additionally would it be worth providing |
I think |
Okay I can create a PR for that. |
I ended up finding a solution to my problem while writing this issue, but I believe it's something that styled-tools should handle by default. I'm working with the sample below which a reakit theme, and the issue is in
contrastText
. What ends up happening is thatbg
resolves to a prop-getter function instead of a string. The reason being thatbgNeedle
is a prop-getter that resolves to a prop-getter which is not supported bywithProp
. What I ended up doing is writing a custom implementation ofwithProp
(below the example) that recursively resolves prop-getter functions. It would be useful if this was either the default behavior ofwithProp
or was exposed as a separate function.Solution
The text was updated successfully, but these errors were encountered: