.

Love the idea of doing some React on here. We need more of it.

However, I'm not sure this kata is a good representation of how "Lifting Up State" should work. The state (the list of inhabitents in each location, in this case) should be stored in "their closest common ancestor", which would be Universe. The Universe should pass two props (a transport handler and a list) down to Planet and Starship. That setup would eliminate the need for componentWillReceiveProps (which is now considered unsafe)

Brilliant kata to get someone started with HOC's.

It might be useful to write a test against hard coding 110 straight into the HOC instead of reading the value from the second parameter passed to withPriceModel.

I enjoyed the atmosphere from the Code Dojo as well. Make sure you ping me again when you organise the next one ;)

We're validating the input value now.

Hey, thanks for your feedback.

I'm not sure I fully understand what part you're saying is not good practice. Could you clarify with an example please?

Hey the method you gave for defining functions is very unique. It needs more ways to pass like passing down functions, and arguments furthur to child components or returning with an arrow function because just doing it your way is not a good practice. If it were just passing down the function with it's arguments to a component within both planet and starship, I would have ok'd that.

Thanks for the feedback; I changed it so that the timerId is now stored on the class, and also mentioned the fetch function more explicitly in the description.

I think there should be a test spying on withPriceModel execution count.
Some of the solutions I see here are creating new component on every render.

Now fixed.

I think you have solved the kata correctly, even using withProps from recompose.

The only thing here is you have not learned to build your own HOC as recompose does that for you.

The point of this kata is to help with getting started building your own HOC.

That is good feedback, perhaps have a couple tests for the fake models to see if withPriceModel can handle different price increases.

I think I might have cheated as well. Maybe we should call withPriceModel ourselves in the test with diferent price increaments