[Minor] Adding componentWillReceieveProps function

[niki4810]

Summary

• When the defaultValue for the radon select is passed via a prop into radon-select from a higher-order parent component, radon-select does not reflect this changes.
• This was because, the internal state of radon-select was never re-set.
• This PR fixes that by adding a componetWillReceieveProps to update the internalState when defaultValue changes
• Also added a simple example to illustrate this in demo page

Screenshot

Before	After

Lint check

//cc @rgerstenberger @exogen @kenwheeler

[alexlande]

You aren't using this value. Should it be used for selectedOptionIndex here?

[alexlande]

Never mind, I can't read.

[exogen]

@niki4810 Hm, this is here from a src update in #39. I assume we only update lib when a new version is published. Can you undo the lib changes?

[rabbitKing]

LGTM.

[alexlande]

I've found updating internal state based on props like this to be a bug-prone pattern, personally. For this case it's a pretty simply set of data you're keeping in sync so it's probably not a big deal. Generally though, I like to follow a pattern where you can either use internal state or have a controlled component using props, but not both at the same time.

That might not make sense here because you have to deal with the selectedOptionIndex prop too, not just the value.

Also, hi @niki4810! 👋 😄

[exogen]

@niki4810 Looks like we don't have CI set up here, but checking this out locally I see some Lint warnings & an error (some from this PR, and a few pre-existing). Can you run npm run lint and get those?

[niki4810]

@exogen will do.

👋 @alexlande

[exogen]

If the user has made a selection and defaultValue changes, will this still reset the selection to the new default? As far as I can tell it would, which seems undesirable to me, but I'm OK with whatever others think.

[niki4810]

@exogen That was my main intention for this change. As in, if the defaultValue is supplied from a store via a higher order component, this component will update it self.

I've noticed, that our dev's were adopting towards a refs based solution, which seemed pretty bad and harder to maintain.

[exogen]

@niki4810 Wouldn't the intention be to update the default if the user hasn't yet made a selection though? Why would the user's explicit choice change just because the default updated?

[niki4810]

@exogen The scenario we are working on is on dropdown change we make a ajax call and if the ajax call fails, we want to re-set the dropdown to its initial state. (or to a previously selected value if applicable).

[exogen]

@niki4810 I suppose if your defaultValue update logic includes a check for potentially updating it to the user's previous selection, then it would be OK. To me it seems like this is asking for a scenario where the user makes a non-default selection, then the default is updated (a seemingly harmless act), and the selection changes unbeknownst to the user, whereupon they submit the form with the wrong value.