Add renderNullWhileWaiting option

[perrin4869]

Only would need to document the new option - if waiting is set to true, and we are not rendering null, we pass a ready flag to the children of I18next. If we're using the HoC, then in order to prevent naming clashes, rename ready as tReady and pass it as a prop to the WrappedComponent

[jamuhl]

Will review and merge tomorrow - and update the documentation for the new options.

Thank you for taking the time to provide the PR.

[perrin4869]

By the way, eslint is complaining about unused state in https://github.com/i18next/react-i18next/pull/400/files#diff-686338533c52a0b5b74b17d3c0e73e9dR104 - any reason it is there?

[jamuhl]

hm...we used to pass that down to the component as prop to trigger rerender -> seems not to be needed anylonger as we changed to use render props...but will need to double check

[tkvw]

Nice, I actually have the exact same problem at the moment. I think the ready prop should be passed down when waiting is false (without setting an option for it). My issue is that I have an additional rerender on initial load, because in my setting waiting is false and I listen for languageChanged event only, but the state will change when ready state is set. I can create a SCU for this, but only if I receive the prop.

So can we pass it through without a special renderNullWhileWaiting prop? I think this adds extra unnecessary complexity to the config.

[jamuhl]

@tkvw means we could simplify

https://github.com/i18next/react-i18next/pull/400/files#diff-686338533c52a0b5b74b17d3c0e73e9dR128

and

https://github.com/i18next/react-i18next/pull/400/files#diff-92a48300b7f85dd6b170af70986e962eR72

to include that in every case. As ready is already set to true on constructing https://github.com/i18next/react-i18next/blob/master/src/I18n.js#L33 i think this should be save.

@perrin4869 what do you think - so we always pass down ready...just avoid returning null in case that renderNullWhileWaiting is set to false.

[tkvw]

@jamuhl : Thanks for pointing out https://github.com/i18next/react-i18next/blob/master/src/I18n.js#L33 , I now make sure languages and the resourcebundles of the default locale are setup correctly so ready will be true on initial render. This solves my problem.

[perrin4869]

OK I will change it so the ready flag is passed regardless of waiting or not!

[perrin4869]

That would make the renderNullWhileWaiting option obsolete btw

[jamuhl]

@perrin4869 no. if both wait and renderNullWhileWaiting are set true it will return null. This new case only applies if wait is set to false.

[perrin4869]

Hm... aren't wait and renderNullWhileWaiting equivalent? What's the difference?
What do you do when wait is true and renderNullWhileWaiting is false?

[jamuhl]

wait: true , ready: false, renderNullWhileWaiting: true -> returns null
wait: true , ready: false, renderNullWhileWaiting: false -> returns component with ready prop false
wait: false, ready: false, renderNullWhileWaiting: true -> returns component with ready prop false

[jamuhl]

honestly we can remove renderNullWhileWaiting ;)

just set wait: false and check for ready prop

[jamuhl]

i think that is even the best solution -> you do not want to wait but you get that ready false to react on

[coveralls]

Coverage decreased (-0.08%) to 81.405% when pulling 36f0400 on perrin4869:ready into 36dad75 on i18next:master.

[perrin4869]

Done! Things should be in order now :)
Just update docs to include the new props/args ready and tReady and ideally write some tests - I'm not acquainted enough with i18next internals to come up with tests promptly.
But it's a straightforward passing down of props so testing should not be critical here

[jamuhl]

will check this tomorrow and merge, publish and update docs where needed

[jamuhl]

published in [email protected]

will update docs in a few minutes / hours (rather busy right now with other stuff)

[jamuhl]

Thanks to all involved making this happen.

[perrin4869]

Thanks for maintaining this as well as always @jamuhl :)

[ChristiaanScheermeijer]

Hi guys, is there an option to disable this behavior? After updating I need to update all translated components which are using {...rest} to inherit props.

[jamuhl]

@ChristiaanScheermeijer can you make a sample - just not get the problem by current description - as i'm aware of there should be no breaking change

[ChristiaanScheermeijer]

Hey @jamuhl, sure!

I have multiple components which are using this pattern:

class LoginButton extends Component {
  render() {
    const { t, ...rest } = this.props;

    return (
      <Button component={Link} to="/login" {...rest}>
        {t('button')}
      </Button>
    );
  }
}

export default providers(
  LoginButton,
  translate('login'),
);

Since now the Button component is receiving an unknown tReady prop, I get the following warning:

Warning: React does not recognize the tReady prop on a DOM element.

[jamuhl]

@ChristiaanScheermeijer i see...i guess there is not much we can do...you will have to change your code i guess -> i would suggest as best practice never pass down ...rest to DOM elements -> use something like https://lodash.com/docs/4.17.10#pick

[ChristiaanScheermeijer]

Ok, I will use this workaround for now:

export const providers = (component, ...wrappers) => {
  let WrappedComponent = component;

  wrappers.forEach(fn => WrappedComponent = fn(WrappedComponent));

  return ({ tReady, ...props}) => <WrappedComponent {...props} />;
};

The ...rest props are being passed down to the material-ui/Button component. I use this to prevent having this multiple times 😅 :

<Button
  component={this.props.component}
  to={this.props.to}
  color={this.props.color}
  disabled={this.props.disabled}
  disableFocusRipple={this.props.disableFocusRipple}
  disableRipple={this.props.disableRipple}
  fullWidth={this.props.fullWidth}
  href={this.props.href}
  mini={this.props.mini}
  size={this.props.size}
  variant={this.props.variant}
  action={this.props.action}
  buttonRef={this.props.buttonRef}
  centerRipple={this.props.centerRipple}
  type={this.props.type}
  {...evenMoreProps}
/>

Thanks for looking into this!