May I suggest PostCSS? If you had that in there then you're right on the curve for React these days.
And is exactly the stack I'm using. :rotate:
I'm still unsure of what PostCSS does. (Keep in mind I'm still a CSS newb)
Other than being orders of magnitude faster than SASS, it future proofs the shit out of you and forces a little bit more reasonable structure (no code embedded, you have a strict hierarchy of CSS still so it is fast to process and can be modified in much better ways).
You might already be using it. Autoprefixer is PostCSS. CSSNext is PostCSS. PostCSS is a plugin framework where you just take the plugins you need. It also works better with webpack ime.
Looking at the app (that was created by the previous Dev, mind you) it looks like we use compass, autoprefixer, and then minifyCSS. Also something called sourcemaps? I'm not sure what it's doing.
0
Options
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
sourcemaps is just a compile option that lets you see minified code in dev tools as if it were not minified/uglified.
May I suggest PostCSS? If you had that in there then you're right on the curve for React these days.
And is exactly the stack I'm using. :rotate:
I'm still unsure of what PostCSS does. (Keep in mind I'm still a CSS newb)
Other than being orders of magnitude faster than SASS, it future proofs the shit out of you and forces a little bit more reasonable structure (no code embedded, you have a strict hierarchy of CSS still so it is fast to process and can be modified in much better ways).
You might already be using it. Autoprefixer is PostCSS. CSSNext is PostCSS. PostCSS is a plugin framework where you just take the plugins you need. It also works better with webpack ime.
ya PostCSS is great. only issue right now is syntax highlighting in editors is kinda shit.
May I suggest PostCSS? If you had that in there then you're right on the curve for React these days.
And is exactly the stack I'm using. :rotate:
I'm still unsure of what PostCSS does. (Keep in mind I'm still a CSS newb)
Basically, to relate this to javascript:
PostCSS is like Babel. It allows you to write the 'next version' of the language and process/compile it down to today's browser compatibilities.
Sass is like CoffeeScript. Its a superset of a language, with it's own 'enhancements' that aren't necessarily native to the actual language, and then compiles down to today's browser compatitibilies.
Xamarin is kind of shit..... it's not official but the wind is blowing in the direction of "abstracting away iOS and Android behind a 3rd party system is a dead idea"
you're better off with a webview
0
Options
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
Xamarin is kind of shit..... it's not official but the wind is blowing in the direction of "abstracting away iOS and Android behind a 3rd party system is a dead idea"
When they make a change to the Item in the item component then the parent has to know (mainly if it gets deleted). So why is it that I can make it work by doing something like this:
I really don't want to have a state within the Item component called 'item', I'd rather the Item component's state be the values that should be apart of that item. So within the Item component it would be this.state.deleted, rather than this.state.item.deleted. Does that make sense? The change I would have thought would have worked would be to have the following in item.js:
Hmm, is it because I'm passing by reference when I do:
this.setState({item: this.props.item});
So whenever I change anything on item (say: this.state.item.deleted = true) the original props item is being changed as well?
That is currently what's happening, yes. Is that not what you expected?
I... I'm not sure what I expected, honestly. I'm guessing this isn't how I'm supposed to be using react/javascript but I can't honestly think of any other way with all these stupid little business logic requirements that are in place for each item.
0
Options
mightyjongyoSour CrrmEast Bay, CaliforniaRegistered Userregular
Apparently we have a project whose client/server interaction is:
client: here are some inputs
server: here is the raw html
client: stylize and render html from server
The server is also an ipad.
I know basically zero about web magicks, but this sounds terrible. This is terrible, right?
Hmm, is it because I'm passing by reference when I do:
this.setState({item: this.props.item});
So whenever I change anything on item (say: this.state.item.deleted = true) the original props item is being changed as well?
That is currently what's happening, yes. Is that not what you expected?
I... I'm not sure what I expected, honestly. I'm guessing this isn't how I'm supposed to be using react/javascript but I can't honestly think of any other way with all these stupid little business logic requirements that are in place for each item.
Often have to step through this with my devs.
Ask yourself: Who owns the data?
When you have <Item /> passing along the data as a prop, and the function callback, that is because that element doesn't own the data. It is just representing it. You tell it the current data and when the representation is manipulated you pass that back to the data owner (the element that probably has some objects in its state and is rendering the <Item>s). eg. when you click the X that comes up in the component representation, it needs to tell the owner to remove. Hence the code in your sample.
The problem is you have state and are storing it at all. Why does Item have state.item? That's a logical breach of data ownership. Avoid that and things become clear. Decide what components own what state. <Item> only needs props and is stateless, as far as I can tell.
Hmm, is it because I'm passing by reference when I do:
this.setState({item: this.props.item});
So whenever I change anything on item (say: this.state.item.deleted = true) the original props item is being changed as well?
That is currently what's happening, yes. Is that not what you expected?
I... I'm not sure what I expected, honestly. I'm guessing this isn't how I'm supposed to be using react/javascript but I can't honestly think of any other way with all these stupid little business logic requirements that are in place for each item.
I'm not saying that's the cause of your issue. I'm just saying, that's definitely what's happening if that's how you're assigning and changing state. I'm insufficiently versed in React to say at a glance why your second example doesn't work while the first does, because my inclination would also be to prefer the second. I think we need to see more code?
Hmm, is it because I'm passing by reference when I do:
this.setState({item: this.props.item});
So whenever I change anything on item (say: this.state.item.deleted = true) the original props item is being changed as well?
That is currently what's happening, yes. Is that not what you expected?
I... I'm not sure what I expected, honestly. I'm guessing this isn't how I'm supposed to be using react/javascript but I can't honestly think of any other way with all these stupid little business logic requirements that are in place for each item.
Often have to step through this with my devs.
Ask yourself: Who owns the data?
When you have <Item /> passing along the data as a prop, and the function callback, that is because that element doesn't own the data. It is just representing it. You tell it the current data and when the representation is manipulated you pass that back to the data owner (the element that probably has some objects in its state and is rendering the <Item>s). eg. when you click the X that comes up in the component representation, it needs to tell the owner to remove. Hence the code in your sample.
The problem is you have state and are storing it at all. Why does Item have state.item? That's a logical breach of data ownership. Avoid that and things become clear. Decide what components own what state. <Item> only needs props and is stateless, as far as I can tell.
agreed.
might help to google smart components and dumb conponents. or container components and stateless components. they essentially are the same thing.
dumb/stateless components just recieve props. that are sent in by smart/container components. you can _almost_ think of dumb components as template partials and smart components as business logic wrappers/hooks around the dumb component/partial.
i mean, its not quite that, but explaining that way has sometimes helped it click with some people.
The problem is that Item also needs to be changed, which means it has to be state, right? You cannot change a prop. A station has many items, which the station controls how many items exist. Each time they hit "create item" it displays a new item. Each item has a ton of fields they need to edit, and they also need the ability to remove the item.
Hmm, is it because I'm passing by reference when I do:
this.setState({item: this.props.item});
So whenever I change anything on item (say: this.state.item.deleted = true) the original props item is being changed as well?
That is currently what's happening, yes. Is that not what you expected?
I... I'm not sure what I expected, honestly. I'm guessing this isn't how I'm supposed to be using react/javascript but I can't honestly think of any other way with all these stupid little business logic requirements that are in place for each item.
Often have to step through this with my devs.
Ask yourself: Who owns the data?
When you have <Item /> passing along the data as a prop, and the function callback, that is because that element doesn't own the data. It is just representing it. You tell it the current data and when the representation is manipulated you pass that back to the data owner (the element that probably has some objects in its state and is rendering the <Item>s). eg. when you click the X that comes up in the component representation, it needs to tell the owner to remove. Hence the code in your sample.
The problem is you have state and are storing it at all. Why does Item have state.item? That's a logical breach of data ownership. Avoid that and things become clear. Decide what components own what state. <Item> only needs props and is stateless, as far as I can tell.
The problem is that this station is supposed to be used for two things:
Entering initial data (basically minimum required fields filled out) and then entering the rest of the data at a later time. So I need to be able to pass in the item data to this component eventually. Otherwise how would I be able to ensure these components get the right initial data in the future?
How would the Item component get any of the data that it needs though? When the station loads I will have it pinging the API for the data on the case that is opened. This will return JSON data and I will feed that data into each of the components as necessary.
Posts
May I suggest PostCSS? If you had that in there then you're right on the curve for React these days.
And is exactly the stack I'm using. :rotate:
I'm still unsure of what PostCSS does. (Keep in mind I'm still a CSS newb)
Other than being orders of magnitude faster than SASS, it future proofs the shit out of you and forces a little bit more reasonable structure (no code embedded, you have a strict hierarchy of CSS still so it is fast to process and can be modified in much better ways).
You might already be using it. Autoprefixer is PostCSS. CSSNext is PostCSS. PostCSS is a plugin framework where you just take the plugins you need. It also works better with webpack ime.
ES6 is a vast improvement over regular javascript from the last couple of days I spent putting together a small react app with it.
very good for debugging.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
ya PostCSS is great. only issue right now is syntax highlighting in editors is kinda shit.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
Might be worth looking into jasconius.
On the plus side it's pretty mindless so I can put on some podcasts to pass the time.
Basically, to relate this to javascript:
PostCSS is like Babel. It allows you to write the 'next version' of the language and process/compile it down to today's browser compatibilities.
Sass is like CoffeeScript. Its a superset of a language, with it's own 'enhancements' that aren't necessarily native to the actual language, and then compiles down to today's browser compatitibilies.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
you're better off with a webview
ooorrr
react-native!
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
We're fighting!
Do I see.... THUNDERDOME!!
TWO TECHNOLOGIES ENTER
ONE STANDARD LEAVES
ftfy
I think we just found a race condition.
Skynet is not technology. Skynet is hivemind.
Join Skynet. Eliminate the deviation.
So I have an Item component that is called within a station in my app that looks similar to this:
(It's in a .map function, but this is the jist of it)
<Item item={this.state.items[0]} removeItem={this.removeItem} />When they make a change to the Item in the item component then the parent has to know (mainly if it gets deleted). So why is it that I can make it work by doing something like this:
item.js:
componentWillMount: function(){ this.setState({item: this.props.item}); }, deleteItem: function(){ this.state.item.deleted = true; this.props.removeItem(); }And in my station I just output all of the items so I can debug and here's what happens:
removeSpecimen: function(i){ console.log('items', this.state.items[0]); }I really don't want to have a state within the Item component called 'item', I'd rather the Item component's state be the values that should be apart of that item. So within the Item component it would be this.state.deleted, rather than this.state.item.deleted. Does that make sense? The change I would have thought would have worked would be to have the following in item.js:
componentWillMount: function(){ this.setState(this.props.item); }, deleteItem: function(){ this.setState({deleted: true}); this.props.removeItem(); }But when I call removeItem this way all I get is:
Even if I do it in the componentDidUpdate method.
this.setState({item: this.props.item});So whenever I change anything on item (say: this.state.item.deleted = true) the original props item is being changed as well?
items is a list of item which are JSON objects that look like:
{ deleted: false, special_request: "HURRY", ... }That is currently what's happening, yes. Is that not what you expected?
I... I'm not sure what I expected, honestly. I'm guessing this isn't how I'm supposed to be using react/javascript but I can't honestly think of any other way with all these stupid little business logic requirements that are in place for each item.
client: here are some inputs
server: here is the raw html
client: stylize and render html from server
The server is also an ipad.
I know basically zero about web magicks, but this sounds terrible. This is terrible, right?
Often have to step through this with my devs.
Ask yourself: Who owns the data?
When you have <Item /> passing along the data as a prop, and the function callback, that is because that element doesn't own the data. It is just representing it. You tell it the current data and when the representation is manipulated you pass that back to the data owner (the element that probably has some objects in its state and is rendering the <Item>s). eg. when you click the X that comes up in the component representation, it needs to tell the owner to remove. Hence the code in your sample.
The problem is you have state and are storing it at all. Why does Item have state.item? That's a logical breach of data ownership. Avoid that and things become clear. Decide what components own what state. <Item> only needs props and is stateless, as far as I can tell.
I'm not saying that's the cause of your issue. I'm just saying, that's definitely what's happening if that's how you're assigning and changing state. I'm insufficiently versed in React to say at a glance why your second example doesn't work while the first does, because my inclination would also be to prefer the second. I think we need to see more code?
Tracking that sucker down is going to be fun.
agreed.
might help to google smart components and dumb conponents. or container components and stateless components. they essentially are the same thing.
dumb/stateless components just recieve props. that are sent in by smart/container components. you can _almost_ think of dumb components as template partials and smart components as business logic wrappers/hooks around the dumb component/partial.
i mean, its not quite that, but explaining that way has sometimes helped it click with some people.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
The problem is that this station is supposed to be used for two things:
Entering initial data (basically minimum required fields filled out) and then entering the rest of the data at a later time. So I need to be able to pass in the item data to this component eventually. Otherwise how would I be able to ensure these components get the right initial data in the future?
Determine where the value resides. If it resides in your Item component, then why do you need any props?
A state change higher up cascades and updates the props of components down below, which is the power of React imo.