Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »

Pollyanna: Mar 5, 2005; Milk's on them.

I'm on a new project using React where we're tasked with building a drop-in component that's basically a form that takes some parameters, has a button to get results, and renders them in a nice looking little graph. I'm inheriting some code for a ticket that implements the code to populate the results from an HTTP call. This branch pulls in react-redux and adds a bunch of Redux-specific code and components, and it's much less simple and straightforward now where our prior approach worked just as well and is easier to develop in. I feel like incorporating react-redux just makes the project more complex for no real advantage or improvement over what we do, and I don't really understand why it's being brought in and integrated. How do I question the reasoning behind using react-redux to people on a project I've newly joined without coming off as pushy or overly questioning?

I guess the main question is, what do I do if I disagree with a proposed approach? I could say "I don't think this is worth it", but I worry that I'd be stepping out of line with that.

Pollyanna fucked around with this message at 21:07 on Dec 7, 2016

# ? Dec 7, 2016 21:00

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 10:22

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Pollyanna posted:

I'm on a new project using React where we're tasked with building a drop-in component that's basically a form that takes some parameters, has a button to get results, and renders them in a nice looking little graph. I'm inheriting some code for a ticket that implements the code to populate the results from an HTTP call. This branch pulls in react-redux and adds a bunch of Redux-specific code and components, and it's much less simple and straightforward now where our prior approach worked just as well and is easier to develop in. I feel like incorporating react-redux just makes the project more complex for no real advantage or improvement over what we do, and I don't really understand why it's being brought in and integrated. How do I question the reasoning behind using react-redux to people on a project I've newly joined without coming off as pushy or overly questioning?

I guess the main question is, what do I do if I disagree with a proposed approach? I could say "I don't think this is worth it", but I worry that I'd be stepping out of line with that.

While I agree with everything you say about Redux... I'd suggest not doing it for awhile? You'll likely get a hostile response and be ostracized as the "difficult to work with/doesn't get it" type. Ask more open ended questions about what React/Redux is doing instead to get explanations, instead of starting arguments.

# ? Dec 7, 2016 21:36

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Skandranon posted:

While I agree with everything you say about Redux... I'd suggest not doing it for awhile? You'll likely get a hostile response and be ostracized as the "difficult to work with/doesn't get it" type. Ask more open ended questions about what React/Redux is doing instead to get explanations, instead of starting arguments.

And since you (Polly, not you Skandranon) seem to bounce between jobs / projects / frameworks faster than anyone I have ever seen, you might learn something by asking questions instead of demanding things be the way you want.

The "complexity" and "extra components" that redux adds in my experience is a good thing, as it allows you to write generic, reusable presentation components that are then made app-specific (or "part of the app" specific) by wrapping in a single redux-based container component. Obviously you can screw this up / over-do it, etc. but I think it's a positive when done correctly, and for good reason.

EDIT: your example is a perfect example on why you would use react-redux. You create a single generic Form, then you can use it all over the place by itself passing params directly, or if you need app-state-dependent things inside, you create container versions of it.

Lumpy fucked around with this message at 22:25 on Dec 7, 2016

# ? Dec 7, 2016 22:20

Pollyanna: Mar 5, 2005; Milk's on them.

Yeah, that's why I didn't want to say anything. It's more likely than not that I have no idea what's going on, so gently caress it, whatever floats their boat.

With that said, I'm wondering how to redirect to another route as part of a reducer/action. Upon hitting a button, we send an action with data from an API and update the store with it. However, Redux is functional and I don't know where something with side effects like Router is used. Is there a particular way to do this in Redux?

# ? Dec 7, 2016 23:14

spacebard: Jan 1, 2007; Football~

Pollyanna posted:

Yeah, that's why I didn't want to say anything. It's more likely than not that I have no idea what's going on, so gently caress it, whatever floats their boat.

With that said, I'm wondering how to redirect to another route as part of a reducer/action. Upon hitting a button, we send an action with data from an API and update the store with it. However, Redux is functional and I don't know where something with side effects like Router is used. Is there a particular way to do this in Redux?

I think that you would change the "route" as part of returning new state in the reducer for that action. Then the app container will pass in the new state to its components props.

The way I do this is I store "route" in a reducer that's passed into the main component, and that loads its conditional child component from there. So the main component's props change when a new route state is returned from the reducer. This is all probably terrible, but I had an unique set of circumstances why I'm implementing my own router rather than using react-redux-router or whatever it's called.

# ? Dec 7, 2016 23:37

Pollyanna: Mar 5, 2005; Milk's on them.

So basically conditional rendering of the child components (where the child components are the different routes), depending on what route is specified in the state? That was what I originally intended to do, but it seemed to be bypassing React-Router altogether. It would be a lot easier, though.

# ? Dec 8, 2016 01:01

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I'm about to get into user rights management stuff for the first time with AngularJS and my Django REST backend. The back end is already managing authentication and only presents data appropriate to the permissions the client current has. I was looking up how to convey this to the front end, and wound up at various GitHub repositories demonstrating code already doing it. Is this the kind of thing I generally want to try to get from a module?

I don't think I have particularly fancy needs. Most of the data is public. There is just a few fields of user-specific data I don't want everybody to see. However, I want users to have a login to associated the things they create with themselves. I pretty much just expect to have the typical login in the corner kind of thing. Should I hunt for helper modules for this?

I otherwise was going to mostly base off of this page to roll something out:
https://medium.com/opinionated-angularjs/techniques-for-authentication-in-angularjs-applications-7bbf0346acec#.vhi0tayvc

That being said, the guy listed some sample projects all the way at the bottom in the comments.

# ? Dec 8, 2016 04:19

luchadornado: Oct 7, 2004; A boombox is not a toy!

Pollyanna posted:

Yeah, that's why I didn't want to say anything. It's more likely than not that I have no idea what's going on, so gently caress it, whatever floats their boat.

With that said, I'm wondering how to redirect to another route as part of a reducer/action. Upon hitting a button, we send an action with data from an API and update the store with it. However, Redux is functional and I don't know where something with side effects like Router is used. Is there a particular way to do this in Redux?

I'd probably just dispatch a route change using https://github.com/reactjs/react-router-redux

code:

dispatch(push('/mynewroute'));

Yes, it is annoying that you likely need React, Redux, React-router, React-router-redux, and Redux-thunk to solve this common use case. That's the downside of an ecosystem fetishizing modularity and un-opinionated libraries over frameworks. The good news is, a lot of these micro-libraries are so small you can easily understand them and use the patterns without actually using them, ie. Redux-thunk: https://github.com/gaearon/redux-thunk/blob/master/src/index.js

It's important that you're honest with your co-workers. There will be times that you need to pick and choose battles, but this doesn't seem like one of them. Any time you bring in a new dependency, especially if it drives significant portions of your stack and/or adds contextual overhead, your team should be open to discussing it. State facts when you know them, but never make or take it personally. Before you hit send on the email or submit on that PR comment ask yourself if you're emotional about the issue in the slightest. If you are: stop immediately, strip out all the emotional crap, ask yourself if it's a battle you want, then ask yourself what you really want as an outcome. Then take a four hour break and give your response.

I hate to get all psychobabble, but understanding the people you work with is really helpful. I'm on a team with a few people that would score high on the "Includer" and "Harmony" Clifton strengths. My principal architect values me because sometimes the team needs a lone dissenter to deny the PR and question why we're doing something.

Don't be afraid not to use Redux, especially if you don't care about time travel. It was the first sane alternative to Flux or rolling your own state manager, and there are valid reasons for not using it. It's biggest sin IMO is the amount of boilerplate that it creates, and the benefits that Lumpy mentioned aren't explicitly provided by it.

luchadornado fucked around with this message at 05:17 on Dec 8, 2016

# ? Dec 8, 2016 05:14

geeves: Sep 16, 2004

Why can't webpack load and bundle together .less files into css like it does JavaScript? Why is it completely different? This is why there will be a replacement for webpack within a year and everyone will be jumping ship.

None of the documentation is clear on exactly what needs to be done. I found a few possible examples on stackoverflow, but none of them seem to work.

I just want to give it an array of files or a directory to use glob.sync on, but It has to be different.

This is what I have. But it's complaining that output.filename is missing.

code:

{
    test: /\.less$/,
    include: "./apps/www/styles/less",
    loader: ExtractTextPlugin.extract('style-loader', 'css-loader!postcss-loader!less-loader?sourceMap')
}

Edit, I just hacked around it for now. Removed the include and added this above. Now just to output to one file.

code:

var less = glob.sync("./apps/www/styles/less/*.less");
for (var i = 0; i < less.length; i++) {
    require(less[i]);
}

It seems to work, but now have illegal tokens to figure out.

geeves fucked around with this message at 05:46 on Dec 8, 2016

# ? Dec 8, 2016 05:32

luchadornado: Oct 7, 2004; A boombox is not a toy!

Dig into how Webpack works under the hood and it will be a bit more clear. It's a JS bundler, and everything else is a hack on top of that. If you treat it as your JS processor and handle everything else separately, your life will be easier. I had SASS compilation working as simple Hello World type thing, but never could get it working well in real-world cases, so chalked it up as another "just because someone made it work, doesn't mean it should work".

Webpack 2 will (supposedly) have decent documentation this time, and will have tree-shaking as its killer feature. I'm guessing it will be the favored JS bundler for the next year or so, as nothing seems ready to overthrow it yet.

luchadornado fucked around with this message at 05:44 on Dec 8, 2016

# ? Dec 8, 2016 05:41

geeves: Sep 16, 2004

Helicity posted:

Dig into how Webpack works under the hood and it will be a bit more clear. It's a JS bundler, and everything else is a hack on top of that. If you treat it as your JS processor and handle everything else separately, your life will be easier. I had SASS compilation working as simple Hello World type thing, but never could get it working well in real-world cases, so chalked it up as another "just because someone made it work, doesn't mean it should work".

Webpack 2 will (supposedly) have decent documentation this time, and will have tree-shaking as its killer feature. I'm guessing it will be the favored JS bundler for the next year or so, as nothing seems ready to overthrow it yet.

Then I misread what webpack was. So I need something separate to handle less. Wonderful.

Edit looks like there's a maven plugin. That should be all I need.

geeves fucked around with this message at 05:52 on Dec 8, 2016

# ? Dec 8, 2016 05:48

luchadornado: Oct 7, 2004; A boombox is not a toy!

geeves posted:

Then I misread what webpack was. So I need something separate to handle less. Wonderful.

Well, it *can* work - a Webpack loader reads in LESS (in your case) and essentially creates a JS module for it that needs to be resolved. This is not super intuitive, the webpack documentation is abyssmal, and all the blog posts and SO posts you're seeing are probably as deep as Hello World. Most people give up and let Webpack do what it's good at, and handle the other things separately. Just pick a LESS processor, create some scripts for building and watching, and tie those in with your JS build steps. You lose out on hot reloading, but that's fairly minor. This is SASS, but it'd be pretty similar to:

code:

"build:css": "node-sass -q --source-map true src/styles/main.scss -o build",
"watch:css": "npm run build:css && node-sass src/styles/main.scss -wo build",
"webpack:hot": "webpack-dev-server --https --hot --content-base build",
"start": "npm run watch:css & npm run webpack:hot"

# ? Dec 8, 2016 05:58

Anony Mouse: Jan 30, 2005; A name means nothing on the battlefield. After a week, no one has a name.; Lipstick Apathy

geeves posted:

Why can't webpack load and bundle together .less files into css like it does JavaScript? Why is it completely different? This is why there will be a replacement for webpack within a year and everyone will be jumping ship.

None of the documentation is clear on exactly what needs to be done. I found a few possible examples on stackoverflow, but none of them seem to work.

I just want to give it an array of files or a directory to use glob.sync on, but It has to be different.

This is what I have. But it's complaining that output.filename is missing.
code:
{
    test: /\.less$/,
    include: "./apps/www/styles/less",
    loader: ExtractTextPlugin.extract('style-loader', 'css-loader!postcss-loader!less-loader?sourceMap')
}
Edit, I just hacked around it for now. Removed the include and added this above. Now just to output to one file.
code:
var less = glob.sync("./apps/www/styles/less/*.less");
for (var i = 0; i < less.length; i++) {
    require(less[i]);
}
It seems to work, but now have illegal tokens to figure out.

This is for SASS but here's part of my webpack.config.js:

code:


	module: {
		loaders: [
			{
				test: /\.(css|sass|scss)$/,
				loader: ExtractTextPlugin.extract("style", "css!sass")
			}
                        ...
		]
	},
	plugins: [
                ...
		new ExtractTextPlugin("styles-[hash].css")
                ...	
	]

Then in my entry file (index.js) I require() every SASS and/or CSS file I need. They all get processed, bundled, and extracted to a single CSS file.

# ? Dec 8, 2016 06:21

Kekekela: Oct 28, 2004

Pollyanna posted:

So basically conditional rendering of the child components (where the child components are the different routes), depending on what route is specified in the state? That was what I originally intended to do, but it seemed to be bypassing React-Router altogether. It would be a lot easier, though.

Yeah, this part is confusing. Initially I was misusing routes (as in react-router routes) for places where I should've just been letting redux state drive.

The paradigm I ended up with was that all the high level areas of our app (think top level nav) are handled by routes, but once you get there everything else is driven by redux state.

Its helpful to view it as your state is a huge ball of data and the route determines the component which renders it.

# ? Dec 8, 2016 12:11

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Helicity posted:

Dig into how Webpack works under the hood and it will be a bit more clear. It's a JS bundler, and everything else is a hack on top of that. If you treat it as your JS processor and handle everything else separately, your life will be easier. I had SASS compilation working as simple Hello World type thing, but never could get it working well in real-world cases, so chalked it up as another "just because someone made it work, doesn't mean it should work".

Webpack 2 will (supposedly) have decent documentation this time, and will have tree-shaking as its killer feature. I'm guessing it will be the favored JS bundler for the next year or so, as nothing seems ready to overthrow it yet.

Webpack 2 documentation is out.

I didn't know it was either until a co-worker was researching Webpack to help me with my issue I posted here earlier. We did get that issue resolved, just had to edit the values in glob.sync(path.join(__dirname, 'js/*.js'))

# ? Dec 8, 2016 15:03

Pollyanna: Mar 5, 2005; Milk's on them.

Helicity posted:

I'd probably just dispatch a route change using https://github.com/reactjs/react-router-redux
code:
dispatch(push('/mynewroute'));
Yes, it is annoying that you likely need React, Redux, React-router, React-router-redux, and Redux-thunk to solve this common use case. That's the downside of an ecosystem fetishizing modularity and un-opinionated libraries over frameworks. The good news is, a lot of these micro-libraries are so small you can easily understand them and use the patterns without actually using them, ie. Redux-thunk: https://github.com/gaearon/redux-thunk/blob/master/src/index.js

It's important that you're honest with your co-workers. There will be times that you need to pick and choose battles, but this doesn't seem like one of them. Any time you bring in a new dependency, especially if it drives significant portions of your stack and/or adds contextual overhead, your team should be open to discussing it. State facts when you know them, but never make or take it personally. Before you hit send on the email or submit on that PR comment ask yourself if you're emotional about the issue in the slightest. If you are: stop immediately, strip out all the emotional crap, ask yourself if it's a battle you want, then ask yourself what you really want as an outcome. Then take a four hour break and give your response.

I hate to get all psychobabble, but understanding the people you work with is really helpful. I'm on a team with a few people that would score high on the "Includer" and "Harmony" Clifton strengths. My principal architect values me because sometimes the team needs a lone dissenter to deny the PR and question why we're doing something.

Don't be afraid not to use Redux, especially if you don't care about time travel. It was the first sane alternative to Flux or rolling your own state manager, and there are valid reasons for not using it. It's biggest sin IMO is the amount of boilerplate that it creates, and the benefits that Lumpy mentioned aren't explicitly provided by it.

Kekekela posted:

Yeah, this part is confusing. Initially I was misusing routes (as in react-router routes) for places where I should've just been letting redux state drive.

The paradigm I ended up with was that all the high level areas of our app (think top level nav) are handled by routes, but once you get there everything else is driven by redux state.

Its helpful to view it as your state is a huge ball of data and the route determines the component which renders it.

This is what I'm thinking, basically. Getting Redux and Router playing nicely together does seem to require bringing in a couple dependencies to do it in a way that isn't confusing or discouraged by said libraries.

After sleeping on Redux, I'm fine with it, but I still can't comprehend what advantage Router brings us in this situation. Especially since this, well, isn't really an app. It's a standalone component with two forms (or just one? Does the output of a black box actually need to be rendered as a form and be expected to also handle input instead of being plain text?) where filling one in and hitting a button fills out the other. I don't see where that use case calls for a routing library, especially since this is meant to be dropped into webpages or other apps that probably handle routing themselves. I would expect the routing to conflict with other routing solutions on the including page, and I sure as hell wouldn't expect a drop-in React component to mess with my URL and browser history.

I know that as a junior developer, I should be listening and not speaking, but I think this is something that deserves some consideration. Maybe that's why I'm bad at this, I dunno. I think I'm gonna bring it up, but obviously not in an accusatory manner. Worse comes to worse, I just ignore the Router and use Redux itself for state changes.

Edit: And I'll also admit that I'm a little emotional about it because figuring out how to integrate the two to accomplish what I want is more complicated than I feel it should be, and that sort of situation makes me feel like things are being done in a way that causes a technical or cognitive burden - and that makes me worry about the ability to grok and maintain a project. Maybe it's a lack of experience, but my gut feeling about this is that it's not going down the right path.

Pollyanna fucked around with this message at 16:09 on Dec 8, 2016

# ? Dec 8, 2016 16:00

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

You should ask "What does this added complexity buy us in the future?" and follow up with "What are we expecting to happen that makes that worth it?" in case their answer doesn't make that obvious after a few minutes of thinking about it.

# ? Dec 8, 2016 17:34

Pollyanna: Mar 5, 2005; Milk's on them.

The answer to those questions is "oh they'll use this component by referencing a webpage that uses it in an iframe". Hence the Routing, apparently. :shrug:

Oh well, not my problem. Now if only they could actually keep track of who is assigned what so that we all don't keep pushing to the same branch independently...

_{if your hot new web 3.0 app is dependent on iframes you might have bigger problems tbqh but hey}

# ? Dec 8, 2016 18:05

PlaneGuy: Mar 28, 2001; g e r m a n
e n g i n e e r i n g; Yam Slacker

Pollyanna posted:

The answer to those questions is "oh they'll use this component by referencing a webpage that uses it in an iframe". Hence the Routing, apparently. Oh well, not my problem. Now if only they could actually keep track of who is assigned what so that we all don't keep pushing to the same branch independently...

_{if your hot new web 3.0 app is dependent on iframes you might have bigger problems tbqh but hey}

it's probably getting embedded into a CMS that doesn't allow you to add js code.

# ? Dec 8, 2016 18:55

Pollyanna: Mar 5, 2005; Milk's on them.

That makes sense.

# ? Dec 8, 2016 18:57

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Pollyanna posted:

That makes sense.

See what happens when you ask questions instead of assuming everything you don't understand is stupid and wrong-headed?

# ? Dec 8, 2016 19:07

HaB: Jan 5, 2001; What are the odds?

Pollyanna posted:

The answer to those questions is "oh they'll use this component by referencing a webpage that uses it in an iframe". Hence the Routing, apparently. Oh well, not my problem. Now if only they could actually keep track of who is assigned what so that we all don't keep pushing to the same branch independently...

_{if your hot new web 3.0 app is dependent on iframes you might have bigger problems tbqh but hey}

And why aren't you branching when working a task? You should pretty much NEVER have two people working on the same branch. Everyone creates new branches off of develop (or whatever your company prefers), and after the PR approval process it gets merged back into develop, which after testing gets merged into production.

# ? Dec 8, 2016 19:21

Gildiss: Aug 24, 2010; Grimey Drawer

Lumpy posted:

See what happens when you ask questions instead of assuming everything you don't understand is stupid and wrong-headed?

The best is thinking it's stupid and wrong-headed, but then not saying anything because who cares and then cash your big paycheck and leave the company in a year.

# ? Dec 8, 2016 20:13

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Gildiss posted:

The best is thinking it's stupid and wrong-headed, but then not saying anything because who cares and then cash your big paycheck and leave the company in a year.

I look at my bank account and lament my lack of apathy far too often.

# ? Dec 8, 2016 20:18

Pollyanna: Mar 5, 2005; Milk's on them.

Lumpy posted:

See what happens when you ask questions instead of assuming everything you don't understand is stupid and wrong-headed?

When did I say that?

HaB posted:

And why aren't you branching when working a task? You should pretty much NEVER have two people working on the same branch. Everyone creates new branches off of develop (or whatever your company prefers), and after the PR approval process it gets merged back into develop, which after testing gets merged into production.

We have one branch per ticket that represents the work done for it. When the ticket was handed off to be, I was under the expectation that I now had ownership of the branch, but the previous dev continued to push to the branch which is something I didn't expect and led me to ask for clarification on who was working on what. In retrospect, I should have just branched off their branch and merged everything back in when I was ready to put up a PR, but still.

# ? Dec 8, 2016 20:54

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Pollyanna posted:

When did I say that?

Your post history is a litany of it. Regardless, I hope thing work out for the best on this and future projects.

# ? Dec 8, 2016 21:47

luchadornado: Oct 7, 2004; A boombox is not a toy!

Pollyanna posted:

We have one branch per ticket that represents the work done for it. When the ticket was handed off to be, I was under the expectation that I now had ownership of the branch, but the previous dev continued to push to the branch which is something I didn't expect and led me to ask for clarification on who was working on what. In retrospect, I should have just branched off their branch and merged everything back in when I was ready to put up a PR, but still.

Your team is treating ticket branches like feature branches. Feature branches are good, but ticket branches are ideally prefixed with your name, ie. helicity.johnson/PL-45667/rip-out-pollyannas-code and then merged into a feature branch or master/develop/whatever depending on size. This type of naming schema is greatly appreciated by non-devs digging through commits and also if you're doing CI/CD. I'd recommend any team do this regardless, but it becomes a necessity once you get to more than a dozen or so devs.

# ? Dec 9, 2016 00:19

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Here is an interesting (to me at least!) article by Remy Sharp about server-side React. He's been somewhat critical of React (in well deserved ways) in other pieces so I was kind of surprised to see it.

https://remysharp.com/2016/12/07/server-side-react

Some good stuff in there.

# ? Dec 9, 2016 15:07

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Lumpy posted:

Here is an interesting (to me at least!) article by Remy Sharp about server-side React. He's been somewhat critical of React (in well deserved ways) in other pieces so I was kind of surprised to see it.

https://remysharp.com/2016/12/07/server-side-react

Some good stuff in there.

It's OK and he does link to a good article - I think I'm just put off by a few things like

quote:

It's from a developer who prefers to be very close to the metal (aka Vanilla JS)

Also, the search query on his own site he links to creates three history entries, so I'm guessing he's rolled his own routing for that (because it's closer to the metal!) and hosed it up lol

# ? Dec 9, 2016 15:46

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Munkeymon posted:

It's OK and he does link to a good article - I think I'm just put off by a few things like

Also, the search query on his own site he links to creates three history entries, so I'm guessing he's rolled his own routing for that (because it's closer to the metal!) and hosed it up lol

You know what, I *always* confuse him with Paul Irish, and so I retract my statement on "he's been critical of React" because these are different people. :facepalm:

# ? Dec 9, 2016 16:06

Kekekela: Oct 28, 2004

"Remy Sharp" posted:

there are some useful React and Redux tools available.

Kind of damning with faint praise here.

# ? Dec 9, 2016 20:34

luchadornado: Oct 7, 2004; A boombox is not a toy!

Munkeymon posted:

It's OK and he does link to a good article - I think I'm just put off by a few things like

I look at it as a polite way of summing up this: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.emrh5d241

# ? Dec 9, 2016 21:24

an skeleton: Apr 23, 2012; scowls @ u

We have an image viewer of sorts in our app which allows a user to upload photos. If this photo is an iOS photo taken in portrait mode, for whatever reason, it is displayed in its side (rotated 90 degrees) instead of upright. right now the image is set into a background, but earlier it was in a regular old <img> tag, and both methods resulted in the img being sideways. anyone have a solution to this? i suppose we can read the metadata and maybe do some css rotation magic, but wanted to reach out before we tried that.

# ? Dec 11, 2016 07:02

geeves: Sep 16, 2004

an skeleton posted:

i suppose we can read the metadata and maybe do some css rotation magic, but wanted to reach out before we tried that.

Are you hosting the image or referencing? CSS could work, but if you read the rotation, you also could change the native image with an image library like imagemagick when they upload. During the upload you can have 3 functions for "Rotate Left, Rotate Right, Rotate 180".

# ? Dec 12, 2016 02:25

an skeleton: Apr 23, 2012; scowls @ u

geeves posted:

Are you hosting the image or referencing? CSS could work, but if you read the rotation, you also could change the native image with an image library like imagemagick when they upload. During the upload you can have 3 functions for "Rotate Left, Rotate Right, Rotate 180".

its a bit of an overwrought process, but basically they upload the image directly to s3 and let us now when that's done, so theres a few different things going on there. i think we've decided on doing an image proxy where we'll be rotating the pictures appropriately on the backend after upload, tl;dr probably won't need to resort to css magic.

# ? Dec 12, 2016 03:59

lunar detritus: May 6, 2009

I have some documents in a mongo database, what would be the best way to transform it into an api?

# ? Dec 12, 2016 13:16

Pollyanna: Mar 5, 2005; Milk's on them.

For React, is there anything wrong with handling different "screens" or views in an app via a state machine/basic "if this then that" approach? e.g. conditionally rendering state via a "currentScreen" variable in the store or something. Is this a popular approach, or discouraged for whatever reason?

# ? Dec 12, 2016 17:13

Depressing Box: Jun 27, 2010; Half-price sideshow.

Pollyanna posted:

For React, is there anything wrong with handling different "screens" or views in an app via a state machine/basic "if this then that" approach? e.g. conditionally rendering state via a "currentScreen" variable in the store or something. Is this a popular approach, or discouraged for whatever reason?

I'd even say conditionally rendering content based on state is one of React's primary functions. I've see a fair amount of React "routing" systems that are basically a bunch of switch statements.

Depressing Box fucked around with this message at 17:34 on Dec 12, 2016

# ? Dec 12, 2016 17:27

Odette: Mar 19, 2011

gmq posted:

I have some documents in a mongo database, what would be the best way to transform it into an api?

Export it into a PostgreSQL database, then use whatever back-end tool you're most comfortable with.

# ? Dec 13, 2016 02:45

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 10:22

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Odette posted:

Export it into a PostgreSQL database, then use whatever back-end tool you're most comfortable with.

ie: stop using Mongo

# ? Dec 13, 2016 03:23

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »