React/Redux - publish component #323

Merged
bones7242 merged 80 commits from react-upload into master 2018-01-25 22:43:20 +01:00
11 changed files with 37 additions and 28 deletions
Showing only changes of commit e482c5f2f8 - Show all commits

View file

@ -51,3 +51,10 @@ export function updateError (name, value) {
value,
};
};
export function updateSelectedChannel (value) {
return {
type: actions.SELECTED_CHANNEL_UPDATE,
value,
};
};

View file

@ -9,3 +9,4 @@ export const CLAIM_UPDATE = 'CLAIM_UPDATE';
export const SET_PUBLISH_IN_CHANNEL = 'SET_PUBLISH_IN_CHANNEL';
export const PUBLISH_STATUS_UPDATE = 'PUBLISH_STATUS_UPDATE';
export const ERROR_UPDATE = 'ERROR_UPDATE';
export const SELECTED_CHANNEL_UPDATE = 'SELECTED_CHANNEL_UPDATE';

View file

@ -0,0 +1,2 @@
export const LOGIN = 'Existing';
export const CREATE = 'New';

View file

@ -1,4 +1,3 @@
// publishing states
export const LOAD_START = 'LOAD_START';
export const LOADING = 'LOADING';
export const PUBLISHING = 'PUBLISHING';

View file

@ -1,11 +1,13 @@
import { connect } from 'react-redux';
import { updateLoggedInChannel } from 'actions/channel';
import View from './view';
import {updateSelectedChannel} from '../../actions/publish';
const mapDispatchToProps = dispatch => {
return {
onChannelLogin: (name, shortId, longId) => {
dispatch(updateLoggedInChannel(name, shortId, longId));
dispatch(updateSelectedChannel(name));
},
};
};

View file

@ -1,11 +1,13 @@
import { connect } from 'react-redux';
import { updateLoggedInChannel } from 'actions/channel';
import View from './view';
import {updateSelectedChannel} from '../../actions/publish';
const mapDispatchToProps = dispatch => {
return {
onChannelLogin: (name, shortId, longId) => {
dispatch(updateLoggedInChannel(name, shortId, longId));
dispatch(updateSelectedChannel(name));
},
};
};

View file

@ -1,11 +1,13 @@
import {connect} from 'react-redux';
import {setPublishInChannel} from 'actions/publish';
import View from './view.jsx';
import {updateSelectedChannel} from '../../actions/publish';
const mapStateToProps = ({ channel, publish }) => {
return {
loggedInChannelName: channel.loggedInChannel.name,
publishInChannel : publish.publishInChannel,
selectedChannel : publish.selectedChannel,
};
};
@ -14,6 +16,9 @@ const mapDispatchToProps = dispatch => {
onPublishInChannelChange: (value) => {
dispatch(setPublishInChannel(value));
},
onChannelSelect: (value) => {
dispatch(updateSelectedChannel(value));
},
};
}

View file

@ -1,29 +1,13 @@
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
import React from 'react';
import ChannelLoginForm from 'containers/ChannelLoginForm';
import ChannelCreateForm from 'containers/ChannelCreateForm';
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
const LOGIN = 'Existing';
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
const CREATE = 'New';
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
import * as states from 'constants/channel_select_states';
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
class ChannelSelect extends React.Component {
constructor (props) {
super(props);
this.state = {
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
selectedOption: LOGIN,
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
};
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
this.toggleAnonymousPublish = this.toggleAnonymousPublish.bind(this);
this.handleSelection = this.handleSelection.bind(this);
this.selectOption = this.selectOption.bind(this);
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
}
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
componentDidMount () {
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
if (this.props.loggedInChannelName) {
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
this.selectOption(this.props.loggedInChannelName);
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
}
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
}
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
componentWillReceiveProps ({ loggedInChannelName }) {
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
if (loggedInChannelName && (loggedInChannelName !== this.props.loggedInChannelName)) {
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
this.selectOption(loggedInChannelName);
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
}
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
}
toggleAnonymousPublish (event) {
const value = event.target.value;
@ -35,10 +19,7 @@ class ChannelSelect extends React.Component {
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
}
handleSelection (event) {
const selectedOption = event.target.selectedOptions[0].value;
this.selectOption(selectedOption);
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
}
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
selectOption (option) {
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
this.setState({selectedOption: option});
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
this.props.onChannelSelect(selectedOption);
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
}
render () {
return (
@ -59,14 +40,14 @@ class ChannelSelect extends React.Component {
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
<div className="column column--3">
<label className="label" htmlFor="channel-name-select">Channel:</label>
</div><div className="column column--7">
<select type="text" id="channel-name-select" className="select select--arrow" value={this.state.selectedOption} onChange={this.handleSelection}>
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
<select type="text" id="channel-name-select" className="select select--arrow" value={this.props.selectedChannel} onChange={this.handleSelection}>
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
{ this.props.loggedInChannelName && <option value={this.props.loggedInChannelName} id="publish-channel-select-channel-option">{this.props.loggedInChannelName}</option> }
<option value={LOGIN}>Existing</option>
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
<option value={CREATE}>New</option>
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
<option value={states.LOGIN}>Existing</option>
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
<option value={states.CREATE}>New</option>
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
</select>
</div>
{ (this.state.selectedOption === LOGIN) && <ChannelLoginForm /> }
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
{ (this.state.selectedOption === CREATE) && <ChannelCreateForm /> }
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
{ (this.props.selectedChannel === states.LOGIN) && <ChannelLoginForm /> }
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
{ (this.props.selectedChannel === states.CREATE) && <ChannelCreateForm /> }
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
</div>
)}
</div>

neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?
neb-b commented 2018-01-18 06:19:56 +01:00 (Migrated from github.com)
Review

Same here, this should be moved to componentDidMount

Same here, this should be moved to `componentDidMount`
neb-b commented 2018-01-18 06:24:14 +01:00 (Migrated from github.com)
Review

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state.

I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen.

Whenever you separate the data into two sources it can cause some weird issues.

Instead of reading prop values and adding them to state, you should just use the prop values and not worry about internal state. I try to avoid internal state whenever possible, one exception is the app homepage, where we store if the user can scroll left or right in a card row. But that isn't dependent on any prop value, just by what is currently on the screen. Whenever you separate the data into two sources it can cause some weird issues.
bones7242 commented 2018-01-19 00:57:08 +01:00 (Migrated from github.com)
Review

@seanyesmunt The issue I am struggling with, is that I (think) I need the <select> element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this <select> element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

@seanyesmunt The issue I am struggling with, is that I (think) I need the `<select>` element to be a controlled component, and if so then it seems like it would be best to use internal state rather than the store, since no other component should care what option is selected unless this component decides to update the state of the store. The reason I am setting the state when the component mounts and when it receives props, is that if another component updates the store when a new channel is logged into, then I want this `<select>` element to re-render with that option selected. Any ideas on how I can approach this differently so that I can eliminate internal state while still accomplishing those goals?

View file

@ -1,6 +1,7 @@
import { connect } from 'react-redux';
import { updateLoggedInChannel } from 'actions/channel';
import View from './view';
import {updateSelectedChannel} from '../../actions/publish';
const mapStateToProps = ({ channel }) => {
return {
@ -14,6 +15,7 @@ const mapDispatchToProps = dispatch => {
return {
onChannelLogin: (name, shortId, longId) => {
dispatch(updateLoggedInChannel(name, shortId, longId));
dispatch(updateSelectedChannel(name));
},
};
};

View file

@ -43,8 +43,10 @@ class NavBar extends React.Component {
let channelName, channelShortId, channelLongId;
({ channelName, channelShortId, channelLongId } = getUserCookies());
console.log(`cookies found for channel: ${channelName} ${channelShortId} ${channelLongId}`);
if (channelName) {
this.props.onChannelLogin(channelName, channelShortId, channelLongId);
}
}
handleSelection (event) {
const value = event.target.selectedOptions[0].value;
switch (value) {

View file

@ -1,7 +1,9 @@
import * as actions from 'constants/action_types';
import * as channelSelectStates from 'constants/channel_select_states';
const initialState = {
publishInChannel: false,
selectedChannel : channelSelectStates.LOGIN,
status : {
status : null,
message: null,
@ -61,6 +63,10 @@ export default function (state = initialState, action) {
[action.name]: action.value,
}),
});
case actions.SELECTED_CHANNEL_UPDATE:
return Object.assign({}, state, {
selectedChannel: action.value,
});
default:
return state;
}