|
Helicity posted:I should have quoted "framework", as that's what I meant - you have to build your own framework as you go. I agree with everything quoted. Create-React-App is about as close as you get to a framework and it's kind of convoluted and very easy to do things the wrong way. Django and .NET MVC are both excellent frameworks that aren't difficult to get started with so it's not like it hasn't been done. Both those frameworks don't really get in your way if you want to replace something useful like the view engine. I don't think it's getting any easier for the React ecosystem, unfortunately. There seems to be some Stockholm Syndrome going on in that community. I agree with everything you're saying, but I'm hopeful that we are moving towards a Django-like place; we're still in the infancy stage I think. Pieces are starting to mature (think the proliferation of state containers / stores / flux implementations coalescing to Redux and Mobx) and some bad implementations of good ideas (React router v1, 2, and 3) actually acknowledging that and moving to something better in v4 (which comes at a cost for sure). Heck, Django did get migrations as an official part of the framework until how many years after it came out?
|
# ? Apr 9, 2017 17:28 |
|
|
# ? Jun 8, 2024 09:30 |
|
I'm wanting to get live reload working with a react and express based site. Is there a way I can develop it using the express server, and have webpack rebuild on changes with the automatic browser refresh that webpack dev server provides? Edit: Nevermind, I forgot Google was a thing, theres a bunch of tutorials on getting hot module replacement working with an Express server. ddiddles fucked around with this message at 23:56 on Apr 9, 2017 |
# ? Apr 9, 2017 23:43 |
|
Generators for ES5 are in TypeScript 2.3 now: https://blogs.msdn.microsoft.com/typescript/2017/04/10/announcing-typescript-2-3-rc/
|
# ? Apr 11, 2017 12:25 |
|
nice I can't wait to delete babel
|
# ? Apr 11, 2017 15:27 |
|
Got a quick React Question (or maybe just a simple question about how .map works) I want to change the values of properties of an object inside an object. My state basically will look like this: code:
JavaScript code:
|
# ? Apr 14, 2017 16:42 |
Grump posted:Wondering how to change fname, lname, etc. I'm sure map() could work, but I'm still not familiar enough with it myself to be able to debug yours at a glance. E:Obviously using Lodash there, but you would likely be able to just do object.assign() directly to the object in the array if you don't care about immutability. ImpactVector fucked around with this message at 17:08 on Apr 14, 2017 |
|
# ? Apr 14, 2017 17:04 |
|
yeah I'm not using Redux, so I'm pretty limited. I just think it's weird that I can target the id no problem, but when I go one tier deeper, it's not finding the properties. e: Looks like I might have to do a map inside of a map? teen phone cutie fucked around with this message at 17:11 on Apr 14, 2017 |
# ? Apr 14, 2017 17:07 |
|
Looks like your previous state had a property called "people" that had an array. Your new state has a property called "entries" instead.
|
# ? Apr 14, 2017 17:20 |
|
ImpactVector posted:
NOICE! That worked. The whole idea is to edit an entry in a contact book, so this definitely helps! Now I just need to implement a search feature and some form validation and baby's first React app will be done! and then i'll go ahead and tackle redux new update function: JavaScript code:
teen phone cutie fucked around with this message at 18:32 on Apr 14, 2017 |
# ? Apr 14, 2017 17:59 |
|
My first major redux project went live this week. Many foot-guns were fired but it definitely feels good to have something out there redux-wise being used by someone other than me. Its a point of sale (plus a billion other scope creeped features) app for our customer service reps, opened it up to 20 this week and everyone else goes on it next week. This is an odd moment of feeling gratified by my profession. Kekekela fucked around with this message at 20:40 on Apr 14, 2017 |
# ? Apr 14, 2017 18:07 |
|
Kekekela posted:My first major redux project went live this week. Many foot-guns were fired but it definitely feels good to have something out there redux-wise being used by someone other than me. Congrats, that is always a good feeling. Until the issues start pouring in! Or so I've heard. I write perfect software.
|
# ? Apr 14, 2017 21:23 |
|
Thermopyle posted:Congrats, that is always a good feeling.
|
# ? Apr 14, 2017 23:20 |
|
I spent 2014-2016 mostly working on a financial product with a tiny user base (that, uh, never launched, at least not yet). Then I started a new job late last year, and now I'm shipping product to tens of thousands of users again, which has been an interesting adjustment. Definitely a lot of "hurray we shipped and people like it!," but also a lot of "oh god it's broken oh no." Doing a lotta things to improve confidence shipping lately. Set up Bugsnag (though we get a ton of noise from lovely third-party scripts our marketing team injects that just break all the drat time), now giving Percy a shot for regression testing. I've wanted to use Percy for a while, but this is the first time I've worked at a company that actually had the budget and the right stack for it (it just goes right into our Capybara feature tests). Really recommend setting up something like Bugsnag (or my personal favorite error reporter, Sentry) for any new app, even if it's small. It's nice knowing that when a user says "hey, your thing broke," it's probably possible to go and find exactly the exception that got thrown. We've also got feature flagging set up, and I'm basically putting literally every new product release under one, so that if it breaks we can shut stuff off. We have a great customer service team that's really good about reporting real problems upstream, so whenever we've had a major bug we've heard about it quickly and been able to disable the feature, which lets us take our time instead of trying a panicked hotfix. Working on a live product is fun, though! I realized I kinda missed it. It's nice to go off and architecture astronaut your way to the Perfect First Release, but there's a neat set of challenges in updating live software too.
|
# ? Apr 15, 2017 04:45 |
|
Can someone give me a tl;dr on what the heck webpack is and why it may/may not be good? The last personal project I did was in ember using browserify and I mostly spend my professional work doing backend stuff. I decided on vue to learn for a new personal project and frontend dev moves too fast for me :|
|
# ? Apr 16, 2017 08:52 |
|
Webpack is a bundler - it automatically pulls all your different bits and bobs together and bundles them all up in a single package. It's pretty robust and fancy if you want to go balls deep on customization, but it can also be really simple if you want it to be too. It's good because it puts all of your junk in a single place, speeding up loading times and doing tree shaking to make sure you're not pulling in wasted files. We have it hooked up to automatically produce debug and release versions, add in instrumentation files for testing and code-coverage, and other fancy stuff like automatic css-preprocessing and typescript compilation. Not bad for a single command. I'd recommend giving it a whirl if you want to take your disparate js, css, and html and putting it together in a single, web-download friendly package.
|
# ? Apr 16, 2017 09:01 |
|
Awesome thanks!
|
# ? Apr 16, 2017 09:03 |
|
Webpack is kind of confusing at first, although there was a push for useful documentation with v2. It's a JS bundler with the added functionality of using loaders to treat anything as JS. Want to compile and minify some CSS or hash your compiled assets for cache-busting and dynamically inject those hashes into your index.htm? Use loaders. webpack-dev-server is really nice too for hot loading changes while you're developing. It's worth learning and embracing for any front-end work IMO. It's been the go-to bundler for several years, there have been attempts to dethrone it, and it just gets better. I went on a purge to remove unnecessary cruft from my personal and work projects, and have settled on Webpack/Typescript always being in every project no matter what.
|
# ? Apr 16, 2017 14:14 |
|
Helicity posted:I went on a purge to remove unnecessary cruft from my personal and work projects, and have settled on Webpack/Typescript always being in every project no matter what. Not too long ago I tried starting a project with just React as a single file dependency and seeing how basic I could make things. Webpack (for module support) was pretty much the first thing I needed to add back in. We've been using Flow instead of TS for type checking, but that'd be high on the list also.
|
# ? Apr 16, 2017 14:22 |
|
I keep meaning to look into Flow, but I am super biased in the matter. Microsoft does languages and tooling really well and Typescript strokes the parts of my brain that miss working with C# on a more regular basis. Facebook got React right and have left me scratching my head in almost every other instance. Is there a recommended unbiased and in-depth breakdown of Flow vs. Typescript?
|
# ? Apr 16, 2017 17:50 |
|
These last two posts confused me since Microsoft Flow is a workflow automation product. Context for anyone as dumb as me: http://flow.org
|
# ? Apr 16, 2017 18:59 |
|
We use flow on our project and its good, but i really feel like the industry is moving more in the direction of TypeScript. It just seems like there's more momentum behind it. I don't have any data to back this up but generally I see typescript typing a lot on 3rd party libraries but not so much for flow.
|
# ? Apr 16, 2017 20:57 |
|
As someone who's mostly worked with AngularJS (or angular 1, whatever they're calling it now), what's a natural, less painful framework for me to pick up? I'm kind of curious about Ember, cause I've heard good things, but I'd rather not sink a lot of time in if no one is using it anymore or if there's something much better.
|
# ? Apr 17, 2017 02:07 |
|
TheCog posted:As someone who's mostly worked with AngularJS (or angular 1, whatever they're calling it now), what's a natural, less painful framework for me to pick up? I'm kind of curious about Ember, cause I've heard good things, but I'd rather not sink a lot of time in if no one is using it anymore or if there's something much better. Vue
|
# ? Apr 17, 2017 02:22 |
|
Vue is good. For marketability, React is probably your best bet. If you want to really expand your mind, try Elm. Typescript is good for either Angular or React.
|
# ? Apr 17, 2017 03:31 |
|
I like flow over typescript mainly because I can drop it into my React apps (using babel for compiling) as I go along without doing anything other than dropping the //@flow comment into files and installing the node_modules type declarations using flow-typed. VS Code's "Flow Language Support" plugin is great at giving you the in-IDE intellisense goodness. Typescript, however, definitely has an advantage over Flowtype in terms of third-part typedefs.
|
# ? Apr 17, 2017 03:33 |
|
TheCog posted:As someone who's mostly worked with AngularJS (or angular 1, whatever they're calling it now), what's a natural, less painful framework for me to pick up? I'm kind of curious about Ember, cause I've heard good things, but I'd rather not sink a lot of time in if no one is using it anymore or if there's something much better. I've been working with (an old version of) Ember for just under a year now at my current gig. It's definitely got a learning curve to it, but overall is pretty decent to work with. The main thing about Ember compared to something like React is that things have to be done the "Ember way" -- it's an extremely opinionated framework. Once you get a handle of what that actually is, it's very easy to work in and reason about. Working with the conventions allows you to skip a lot of boilerplate and be productive quicker. Ember-CLI also takes care of the build pipeline out of the box so you don't really need to worry about configuring a bunch of poo poo to deploy production code (whereas with React you have to configure Webpack, etc). Ember is moving in a pretty interesting direction now IMO. They've ditched the MVC architecture for what our lead Ember guy calls CRS - components, routes and services, which more closely aligns with modern front-end SPA development principles. They've also broken out their core rendering engine (Glimmer.js) into its own view library and destructured Ember itself to be much more modular -- you can define exactly what your application needs and nothing more. I haven't actually seen much of this stuff though, since we were a very early adopter of Ember and are in the process of getting up to date with modern Ember. It's not as popular as some of the other leading front-end technologies right now, but I think Ember has some decent legs behind it. LinkedIn/Microsoft recently hired a bunch of Ember core people and general interest in the frame work seems to be trending upwards in recent surveys, so at least in the short term it seems like some cool things can come out of it. I do agree though that if you want to be more marketable right away you should look into React.
|
# ? Apr 18, 2017 04:58 |
|
Would the following setup make sense? - Node running an API backend that connects to my database, proxied to Nginx as /api - Nginx serving the webpack'd React frontend statically as /, that uses ajax calls to pull data from /api I think that makes more sense than having everything be served by the same Node application, but I'm not sure. Maybe I'm just making things needlessly complicated. Count Thrashula fucked around with this message at 18:07 on Apr 18, 2017 |
# ? Apr 18, 2017 18:04 |
|
Yeah, I think that's a pretty common setup
|
# ? Apr 18, 2017 18:08 |
|
We've been wrestling for weeks with a problem where our app doesn't work on IE or Safari or what have you, and only now are we figuring out why: String.startsWith isn't available on IE11. What fucks me up is that we're already using Lodash, which works just fine on IE11 and has startsWith, yet the people who propagated the original, non-portable solution didn't even bother to use it or check to see if their own solution worked on one of our target browsers. I thought this poo poo was front-end 101? Like, really goddamn basic? This whole thing makes me sad. The project has been an exercise in how not to make a front-end.
|
# ? Apr 18, 2017 18:28 |
|
Pollyanna posted:The project has been an exercise in how not to make a front-end. This is what web dev 101 actually is. . . . And web dev 9000. It doesn't end. Learn to love the Sisyphean nightmare.
|
# ? Apr 18, 2017 18:46 |
|
Pollyanna posted:We've been wrestling for weeks with a problem where our app doesn't work on IE or Safari or what have you, and only now are we figuring out why: String.startsWith isn't available on IE11. What fucks me up is that we're already using Lodash, which works just fine on IE11 and has startsWith, yet the people who propagated the original, non-portable solution didn't even bother to use it or check to see if their own solution worked on one of our target browsers. I thought this poo poo was front-end 101? Like, really goddamn basic?
|
# ? Apr 18, 2017 18:52 |
|
We use a top level polyfills.io call that covers a lot of the bases like fetch and Promises that IE stumbles on. It does wonders for plugging random holes like that: https://polyfill.io/v2/docs/
|
# ? Apr 18, 2017 23:36 |
|
COOL CORN posted:Would the following setup make sense? This is the right way to do it, and very common. Decouple and embrace the strangler pattern. nginx will do a better job of serving up static content than node, and *anything* you can offload from your web app is a good thing and one less thing that can cause resource contention and downtime. See https://dzone.com/articles/benefits-reverse-proxy
|
# ? Apr 19, 2017 00:07 |
|
Pollyanna posted:We've been wrestling for weeks with a problem where our app doesn't work on IE or Safari or what have you, and only now are we figuring out why: String.startsWith isn't available on IE11. What fucks me up is that we're already using Lodash, which works just fine on IE11 and has startsWith, yet the people who propagated the original, non-portable solution didn't even bother to use it or check to see if their own solution worked on one of our target browsers. I thought this poo poo was front-end 101? Like, really goddamn basic? How does that take more than navigating to the web page once with "disable script debugging" disabled in IE to figure out?
|
# ? Apr 19, 2017 11:10 |
|
First you have to remember how to run IE11 from your Mac...
|
# ? Apr 19, 2017 12:16 |
|
smackfu posted:First you have to remember how to run IE11 from your Mac... and that's at least a week right there.
|
# ? Apr 19, 2017 12:25 |
|
smackfu posted:First you have to remember how to run IE11 from your Mac... Who officially supports IE these days?
|
# ? Apr 19, 2017 14:30 |
|
geeves posted:Who officially supports IE these days? People who write web apps and make websites? I guess if your company is so successful it can ignore 25-35% of humanity, good for you, but most can't.
|
# ? Apr 19, 2017 14:55 |
|
We almost had to develop exclusively on IE at Bank of America after an IT director saw a dev change a dollar amount using the dev console. He issued an order to force all devs to remove Chrome. There was obviously push back but I don't think he got called a retard which is unfortunate.
|
# ? Apr 19, 2017 15:13 |
|
|
# ? Jun 8, 2024 09:30 |
|
Gildiss posted:We almost had to develop exclusively on IE at Bank of America after an IT director saw a dev change a dollar amount using the dev console. He issued an order to force all devs to remove Chrome. IT director, technologically challenged? No way.
|
# ? Apr 19, 2017 15:16 |