It is necessary to handle destructuring while performing this task, whether it be seen as unfortunate or fortunate.
type Props = {
icon: number,
onChangeText: Function,
onEndEditing: Function,
placeholder: string,
secureTextEntry?: boolean
};
function LRInput(
{ secureTextEntry = false, ...props }: Props
) { console.log(secureTextEntry) }
LRInput({ icon: 5 })
LRInput({ icon: 5, secureTextEntry: true })
Edit
In response to your concern about the default value appearing after the rest of the props, when targeting es5 in typescript, there should not be an issue because the rest syntax is transpiled accordingly as shown below,
function LRInput(_a) {
var _b = _a.secureTextEntry;
var secureTextEntry = _b === void 0 ? false : _b;
/* code to handle rest omitted */
console.log(secureTextEntry);
}
It is evident that with this transformation, the order of spread does not affect functionality. However, for logical coherence, ES2018 standard and Typescript dictate placing the "rest" parameter after the destructured keys
{ secureTextEntry = false, ...rest }
.
(My oversight initially occurred due to editing the code which executed without error on this site's typescript compiler set to emit despite detecting errors. Since I did not utilize ...props
within the function, the issue with rest parameter transformation went unnoticed. You can witness the transpilation process here for yourself.)