Update Transition type definition

[lasseborly]

This PR reflects some of the thought put out in #26 (comment).

From reading some of the recent PR's I can see that having a literal boolean type on Transition has been discussed in #84 but never seemed to have gotten implemented.
The TS compiler throws an error if a literal boolean false type is being substituted for this PR's basic boolean type. A simple type discrepancy. Therefore boolean is used instead.

I'll modify as needed.

Thanks for a great lib @drcmda 👍

[drcmda]

The readme additions are great. Could you take another look into the definition though - there seems to be a mistake as children/render can't take boolean types, they can take a ternary which yields a function or undefined.

[drcmda]

@lasseborly {visible && fn} isn't a boolean, though. It either results in a function of undefined.

[drcmda]

same here.

[lasseborly]

@drcmda I see your point. Will correct.

[lasseborly]

@drcmda corrected!

[epilande]

This will definitely clear up some confusion 👍

[lasseborly]

@drcmda is there anything else I can do to make this go through?
Would love to get off of my own fork and correct my dependency.

[drcmda]

@lasseborly i'll merge and release today. wasn't with a computer over the last week, we made a small trip to rome :-)

[lasseborly]

Sounds lovely @drcmda !

[drcmda]

@lasseborly

Just went through, boolean still seems to be part of children and render

  children?:
    | SpringRendererFunc<S, DS>
    | Array<SpringRendererFunc<S, DS>>
    | boolean

  render?:
    | SpringRendererFunc<S, DS>
    | Array<SpringRendererFunc<S, DS>>
    | boolean

Could i see a snippet of code that depends on your fork? Because it seems strange, children/render shouldn't take booleans, only functions and ternaries that yield functions, or undefined.

[lasseborly]

@drcmda so when we do the single component transition TS interprets that as children/render being a boolean if toggle is falsy.

I made a codesandbox so you can see the problem for yourself.
This problem get's solved if we add the boolean possibility to the TS type def.
This is also why I made a reference to a previous PR #84 which tried to solve this by adding a literal type. The literal type is not the correct solution though, because TS still interprets the expressions to have the possibility of being a boolean.

[lasseborly]

I can see the argument for not having the boolean prop-type on the JS side of things, since as you pointed out this evaluates to undefined and not specifically false and therefore only a falsy type not an actual boolean.

[drcmda]

Just checking if it's correct - i have yet to dig into TS. If it helps TS knowing undefined i guess it's fine. I'll run some errands and release later this day.