React/Redux - publish component #323
|
|
@ -10,12 +10,10 @@ class Preview extends React.Component {
|
|||
Generally you should avoid doing dom stuff/setting state in
Generally you should avoid doing dom stuff/setting state in `componentWillMount`. Especially since it seems that they will be removing it in a future React version.
`componentDidMount` is preferred
|
||||
};
|
||||
this.previewFile = this.previewFile.bind(this);
|
||||
}
|
||||
componentWillMount () {
|
||||
|
Generally you should avoid doing dom stuff/setting state in
Generally you should avoid doing dom stuff/setting state in `componentWillMount`. Especially since it seems that they will be removing it in a future React version.
`componentDidMount` is preferred
|
||||
console.log('Preview will mount');
|
||||
|
Generally you should avoid doing dom stuff/setting state in
Generally you should avoid doing dom stuff/setting state in `componentWillMount`. Especially since it seems that they will be removing it in a future React version.
`componentDidMount` is preferred
|
||||
componentDidMount () {
|
||||
|
Generally you should avoid doing dom stuff/setting state in
Generally you should avoid doing dom stuff/setting state in `componentWillMount`. Especially since it seems that they will be removing it in a future React version.
`componentDidMount` is preferred
|
||||
this.previewFile(this.props.file);
|
||||
}
|
||||
componentWillReceiveProps (newProps) {
|
||||
console.log('Preview will receive props', newProps);
|
||||
|
Generally you should avoid doing dom stuff/setting state in
Generally you should avoid doing dom stuff/setting state in `componentWillMount`. Especially since it seems that they will be removing it in a future React version.
`componentDidMount` is preferred
|
||||
if (newProps.file !== this.props.file) {
|
||||
this.previewFile(newProps.file);
|
||||
}
|
||||
|
|
|
|||
|
Generally you should avoid doing dom stuff/setting state in
Generally you should avoid doing dom stuff/setting state in `componentWillMount`. Especially since it seems that they will be removing it in a future React version.
`componentDidMount` is preferred
Generally you should avoid doing dom stuff/setting state in
Generally you should avoid doing dom stuff/setting state in `componentWillMount`. Especially since it seems that they will be removing it in a future React version.
`componentDidMount` is preferred
|
||||
|
|
@ -21,7 +21,7 @@ class ProgressBar extends React.Component {
|
|||
|
What is the What is the `|` doing here?
It looks as if its seeding the progress visually, is that correct? It looks as if its seeding the progress visually, is that correct?
Instead of adding react elements to state, just store the data. Then in the Instead of adding react elements to state, just store the data.
Then in the `render` function, you can do
`this.state.bars.map((bar, index) => bar.isActive ? <ActiveBar key={index} /> : <InactiveBar key={index} />)`
Yes, I am rendering the Yes, I am rendering the `|`s for the progress bars
What is the What is the `|` doing here?
It looks as if its seeding the progress visually, is that correct? It looks as if its seeding the progress visually, is that correct?
Instead of adding react elements to state, just store the data. Then in the Instead of adding react elements to state, just store the data.
Then in the `render` function, you can do
`this.state.bars.map((bar, index) => bar.isActive ? <ActiveBar key={index} /> : <InactiveBar key={index} />)`
Yes, I am rendering the Yes, I am rendering the `|`s for the progress bars
|
||||
this.updateProgressBar = this.updateProgressBar.bind(this);
|
||||
this.stopProgressBar = this.stopProgressBar.bind(this);
|
||||
}
|
||||
componentWillMount () {
|
||||
|
What is the What is the `|` doing here?
It looks as if its seeding the progress visually, is that correct? It looks as if its seeding the progress visually, is that correct?
Instead of adding react elements to state, just store the data. Then in the Instead of adding react elements to state, just store the data.
Then in the `render` function, you can do
`this.state.bars.map((bar, index) => bar.isActive ? <ActiveBar key={index} /> : <InactiveBar key={index} />)`
Yes, I am rendering the Yes, I am rendering the `|`s for the progress bars
|
||||
componentDidMount () {
|
||||
|
What is the What is the `|` doing here?
It looks as if its seeding the progress visually, is that correct? It looks as if its seeding the progress visually, is that correct?
Instead of adding react elements to state, just store the data. Then in the Instead of adding react elements to state, just store the data.
Then in the `render` function, you can do
`this.state.bars.map((bar, index) => bar.isActive ? <ActiveBar key={index} /> : <InactiveBar key={index} />)`
Yes, I am rendering the Yes, I am rendering the `|`s for the progress bars
|
||||
const bars = [];
|
||||
for (let i = 0; i <= this.state.size; i++) {
|
||||
bars.push(<InactiveBar key={i} />);
|
||||
|
|
|
|||
|
What is the What is the `|` doing here?
It looks as if its seeding the progress visually, is that correct? It looks as if its seeding the progress visually, is that correct?
Instead of adding react elements to state, just store the data. Then in the Instead of adding react elements to state, just store the data.
Then in the `render` function, you can do
`this.state.bars.map((bar, index) => bar.isActive ? <ActiveBar key={index} /> : <InactiveBar key={index} />)`
Yes, I am rendering the Yes, I am rendering the `|`s for the progress bars
What is the What is the `|` doing here?
It looks as if its seeding the progress visually, is that correct? It looks as if its seeding the progress visually, is that correct?
Instead of adding react elements to state, just store the data. Then in the Instead of adding react elements to state, just store the data.
Then in the `render` function, you can do
`this.state.bars.map((bar, index) => bar.isActive ? <ActiveBar key={index} /> : <InactiveBar key={index} />)`
Yes, I am rendering the Yes, I am rendering the `|`s for the progress bars
|
||||
|
|
@ -16,8 +16,8 @@ function UrlMiddle ({publishInChannel, loggedInChannelName, loggedInChannelShort
|
|||
|
||||
UrlMiddle.propTypes = {
|
||||
publishInChannel : PropTypes.bool.isRequired,
|
||||
loggedInChannelName : PropTypes.string.isRequired,
|
||||
loggedInChannelShortId: PropTypes.string.isRequired,
|
||||
loggedInChannelName : PropTypes.string,
|
||||
loggedInChannelShortId: PropTypes.string,
|
||||
};
|
||||
|
||||
export default UrlMiddle;
|
||||
|
|
|
|||
|
|
@ -15,8 +15,7 @@ class ChannelSelect extends React.Component {
|
|||
|
Same here, this should be moved to Same here, this should be moved to `componentDidMount`
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.
@seanyesmunt The issue I am struggling with, is that I (think) I need the @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?
Same here, this should be moved to Same here, this should be moved to `componentDidMount`
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.
@seanyesmunt The issue I am struggling with, is that I (think) I need the @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.handleSelection = this.handleSelection.bind(this);
|
||||
this.selectOption = this.selectOption.bind(this);
|
||||
}
|
||||
componentWillMount () {
|
||||
|
Same here, this should be moved to Same here, this should be moved to `componentDidMount`
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.
@seanyesmunt The issue I am struggling with, is that I (think) I need the @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?
|
||||
console.log('ChannelSelector will mount');
|
||||
|
Same here, this should be moved to Same here, this should be moved to `componentDidMount`
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.
@seanyesmunt The issue I am struggling with, is that I (think) I need the @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 () {
|
||||
|
Same here, this should be moved to Same here, this should be moved to `componentDidMount`
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.
@seanyesmunt The issue I am struggling with, is that I (think) I need the @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) {
|
||||
this.selectOption(this.props.loggedInChannelName);
|
||||
}
|
||||
|
|
|
|||
|
Same here, this should be moved to Same here, this should be moved to `componentDidMount`
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.
@seanyesmunt The issue I am struggling with, is that I (think) I need the @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?
Same here, this should be moved to Same here, this should be moved to `componentDidMount`
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.
@seanyesmunt The issue I am struggling with, is that I (think) I need the @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?
|
||||
|
|
@ -15,7 +15,7 @@ class PublishForm extends React.Component {
|
|||
this.makePublishRequest = this.makePublishRequest.bind(this);
|
||||
this.publish = this.publish.bind(this);
|
||||
}
|
||||
componentWillMount () {
|
||||
componentDidMount () {
|
||||
// check for whether a channel is already logged in
|
||||
const loggedInChannelName = getCookie('channel_name');
|
||||
const loggedInChannelShortId = getCookie('short_channel_id');
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ class PublishUrlInput extends React.Component {
|
|||
this.setClaimNameFromFileName = this.setClaimNameFromFileName.bind(this);
|
||||
this.checkClaimIsAvailable = this.checkClaimIsAvailable.bind(this);
|
||||
}
|
||||
componentWillMount () {
|
||||
componentDidMount () {
|
||||
if (!this.props.claim || this.props.claim === '') {
|
||||
this.setClaimNameFromFileName();
|
||||
}
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ module.exports = {
|
|||
|
GIFs GIFs
I'm interested in the direction of this PR, it seems to be purposed as an image sharing service as per required. .png .jpeg .gif ... requirements. Can we still publish video and is there support for generic file types? It just feels like its moving away from video upload and I wanted to be clear. I'm interested in the direction of this PR, it seems to be purposed as an image sharing service as per required. .png .jpeg .gif ... requirements. Can we still publish video and is there support for generic file types? It just feels like its moving away from video upload and I wanted to be clear.
@etisdew yes @etisdew yes `video/mp4` is supported and supporting video uploads is a key goal for spee.ch
GIFs GIFs
I'm interested in the direction of this PR, it seems to be purposed as an image sharing service as per required. .png .jpeg .gif ... requirements. Can we still publish video and is there support for generic file types? It just feels like its moving away from video upload and I wanted to be clear. I'm interested in the direction of this PR, it seems to be purposed as an image sharing service as per required. .png .jpeg .gif ... requirements. Can we still publish video and is there support for generic file types? It just feels like its moving away from video upload and I wanted to be clear.
@etisdew yes @etisdew yes `video/mp4` is supported and supporting video uploads is a key goal for spee.ch
|
||||
case 'image/gif':
|
||||
if (file.size > 50000000) {
|
||||
console.log('file was too big');
|
||||
throw new Error('Sorry, .gifs are limited to 50 megabytes.');
|
||||
|
GIFs GIFs
I'm interested in the direction of this PR, it seems to be purposed as an image sharing service as per required. .png .jpeg .gif ... requirements. Can we still publish video and is there support for generic file types? It just feels like its moving away from video upload and I wanted to be clear. I'm interested in the direction of this PR, it seems to be purposed as an image sharing service as per required. .png .jpeg .gif ... requirements. Can we still publish video and is there support for generic file types? It just feels like its moving away from video upload and I wanted to be clear.
@etisdew yes @etisdew yes `video/mp4` is supported and supporting video uploads is a key goal for spee.ch
|
||||
throw new Error('Sorry, GIFs are limited to 50 megabytes.');
|
||||
|
GIFs GIFs
I'm interested in the direction of this PR, it seems to be purposed as an image sharing service as per required. .png .jpeg .gif ... requirements. Can we still publish video and is there support for generic file types? It just feels like its moving away from video upload and I wanted to be clear. I'm interested in the direction of this PR, it seems to be purposed as an image sharing service as per required. .png .jpeg .gif ... requirements. Can we still publish video and is there support for generic file types? It just feels like its moving away from video upload and I wanted to be clear.
@etisdew yes @etisdew yes `video/mp4` is supported and supporting video uploads is a key goal for spee.ch
|
||||
}
|
||||
break;
|
||||
case 'video/mp4':
|
||||
|
|
|
|||
|
GIFs GIFs
I'm interested in the direction of this PR, it seems to be purposed as an image sharing service as per required. .png .jpeg .gif ... requirements. Can we still publish video and is there support for generic file types? It just feels like its moving away from video upload and I wanted to be clear. I'm interested in the direction of this PR, it seems to be purposed as an image sharing service as per required. .png .jpeg .gif ... requirements. Can we still publish video and is there support for generic file types? It just feels like its moving away from video upload and I wanted to be clear.
@etisdew yes @etisdew yes `video/mp4` is supported and supporting video uploads is a key goal for spee.ch
GIFs GIFs
I'm interested in the direction of this PR, it seems to be purposed as an image sharing service as per required. .png .jpeg .gif ... requirements. Can we still publish video and is there support for generic file types? It just feels like its moving away from video upload and I wanted to be clear. I'm interested in the direction of this PR, it seems to be purposed as an image sharing service as per required. .png .jpeg .gif ... requirements. Can we still publish video and is there support for generic file types? It just feels like its moving away from video upload and I wanted to be clear.
@etisdew yes @etisdew yes `video/mp4` is supported and supporting video uploads is a key goal for spee.ch
|
||||
Generally you should avoid doing dom stuff/setting state in
componentWillMount. Especially since it seems that they will be removing it in a future React version.componentDidMountis preferred