Open vit-svoboda opened 6 years ago
Honestly, I did not read the milestone at all :/ We will catch up. :)
We discuss naming and structure of actions at the lecture. Your colleagues were not able to clarify what is the desired state.
By ADD_CHANNEL I meant to describe what action user is willing to do. (From Redux doc: ADD_TODO). Does your suggestion apply to only thunk actions? If so, I think action creator should be still named addChannel(...) since it is natural to call addChannel(...) function in a component. (I expect the use of mapDispatchToProps shorthand).
Thank you for clarification.
PS. Klidne muzeme prepnout do cestiny. ;-)
I'm afraid there must've been a misunderstanding in regards to the second milestone. I appreciate the extra effort to implement the back-end calls. However, a lot more features should've been implemented by now, albeit only locally in the browser. I can add a channel and once you're done with API authentication, the channel will be really added. But I can't switch channels, I can't add messages to the channels (and it would've been absolutely fine if the messages disappeared after browser refresh), I can't delete or up/downvote messages etc.
Code suggestions
CHANNEL_ADDITION_STARTED
,CHANNEL_ADDITION_FAILED
) and the reducers decide how (and whether) to modify the application state when the event happened. Of course, the actions carry payload that the reducers may need to react to the event, but should not dictate the change in any way.Or if you want to be explicit:
You can use
reselect
to do that, but it's optional unless you create new objects in this state cherry-picking process. That creates the need some form of memoization. Anyway, same principle applies to the selector body, don't make it too boring to read. 😄