Hi Dan,

I'm using Redux with react-redux and I'm familiar with Provider + HOC design pattern.

I have another case. A Locale service which registers listeners and when locale (dir or lang) is changed it notifies all registered listeners.

My current approach is: All React components that are interested in locale change are wrapped with a HOC (ex: MyComp = localeAware(MyComp)) which provides them with a locale object in props. Then MyComp will just read locale from this.props.locale.

What localeAware HOC does now is: it registers itself directly to the Locale service.

If I would have 100 localeAware components the service will loop through all registered listeners and call them with new locale object.

Another way that this could be done would be to have LocaleProvider similar with Redux Provider which would register itself to Locale service and share via React context a registration API into which all localeAware HOCs will register their callbacks.

The difference now will be that localeAware HOCs will NOT register directly to Locale service BUT will register to LocaleProvider via context. If I would have 100 localeAware components, the LocaleProvider would be in charge this time to loop through all them and call their callbacks.

Both approaches will require some form of registrations and a looping through registered callbacks.

My questions are:

Would it be better that localeAware HOC to connect to a LocaleProvider via context OR connect directly to the service and why ? What would be the advantage of having another layer (the Provider) between localeAware HOC and the service ? Is there a difference between my case and react-redux case ? If not asking too much, what was the reason behind the decision that mapStateToProps from react-redux to connect to the Provider instead of directly to the Store ? Really trying to understand the general reason of having another indirection layer (the Provider) between the HOC and the source of information, when this design makes sense and when it does not.

Thanks a lot