|
I think most are in agreement that starting something brand new with AngularJS would be a poor decision, because the mindshare has mostly moved on from it and there's a wealth of strong alternatives. But if you're already sitting on an AngularJS code base there's no need to panic about a migration path or switching over soon as it's still a very solid solution to the problem of organizing a dynamic front end and will be supported for quite a while into the future.
|
#
?
Apr 1, 2017 22:43
|
|
|
|
| # ? Jun 6, 2024 15:10 |
|
|
Are you all staying at positions that would even warrant this long term thinking? My last 2 years have been going from burning wreckage to burning wreckage. I feel like I'm in a season of walking dead seeing an idyllic place and watching it destroyed from within by idiots and then everyone dies or is scattered to the winds.
|
|
#
?
Apr 2, 2017 00:39
|
|
|
I've been working at the same company for over ten years. I really love my company but the fantasy of making a clean break from all the lovely code that I've shipped over the past decade is definitely nice sometimes.
|
|
#
?
Apr 2, 2017 00:50
|
|
|
It's hard to find good developers to work on old tech, keep in mind. Most of the really good front-end developers I know consider seeing Angular 1, jQuery, Knockout, Backbone, etc. in open req descriptions as a sign that a company doesn't invest in paying down tech debt, and consequently they'll look for something different.Gildiss posted:Are you all staying at positions that would even warrant this long term thinking? There are a handful of places in Minnesota that are easily good enough to stay at beyond 2 years. I'd imagine hotter markets like CO or Austin have even more.
|
|
#
?
Apr 2, 2017 02:08
|
|
|
Helicity posted:It's hard to find good developers to work on old tech, keep in mind. Most of the really good front-end developers I know consider seeing Angular 1, jQuery, Knockout, Backbone, etc. in open req descriptions as a sign that a company doesn't invest in paying down tech debt, and consequently they'll look for something different. This is something I am trying to get across to the current shop I work in. It's perfectly possible to find a sane and workable upgrade path. We still build apps on pre 1.5 Angular and a few of us who have been at shops using something more modern all hate it. The tool chain is clunky too. They are still using grunt/bower for everything and once you have used webpack, going back to grunt/bower is painful. So we are trying to drag them at least slightly forward into Typescript/Angular 1.5. Most annoying thing is they don't offer any reason why they stay on that tool chain aside from "reasons".
|
|
#
?
Apr 2, 2017 02:32
|
|
|
Skandranon posted:It really depends how your AngularJS apps are written. A lot of the components/services in mine could actually be used in Angular 2 verbatim, with only a few line changes to register them in Angular 2. So in this case, I am expecting what could be called a migration.
|
|
#
?
Apr 3, 2017 17:51
|
|
|
Summit posted:Nobody should really be saying "Angular 4" much like nobody says "React 15" (current version, since they also do semver). I'll admit Angular team has handled this situation very poorly but the piling on about version numbers is pretty silly. The difference is that there is not a completely different thing named React 1 which people use and you need to distinguish it from.
|
|
#
?
Apr 3, 2017 18:50
|
|
|
While refactoring some stuff today a Jest snapshot test caught a bug that I would've introduced, where in some cases a number would've been formatted incorrectly. Its the kind of little thing that could've easily gone undetected and just made the app look sloppy when eventually it got noticed. This is definitely the warmest/fuzziest I have ever felt about client side testing.
|
|
#
?
Apr 5, 2017 17:27
|
|
|
Kekekela posted:While refactoring some stuff today a Jest snapshot test caught a bug that I would've introduced, where in some cases a number would've been formatted incorrectly. Its the kind of little thing that could've easily gone undetected and just made the app look sloppy when eventually it got noticed. This is definitely the warmest/fuzziest I have ever felt about client side testing. Me a few months into a project in which I started testing up front: "Oh man, I'm so glad I've been writing tests, that saved my butt!" Me a few months into a project in which no testing was done up front: "Fuuuuuucckkkkkkkk...... I wish I had time to write tests, but there's all these bugs to fix....  "
|
|
#
?
Apr 5, 2017 17:37
|
|
|
So, my current task has been to put new features on a kinda huge React app, and it's stable and works, so it's all fine and dandy, but also to keep it up to date. Only this was made in an old React version, 0.12; I've been making small progresses to upgrade it to v15, but there's a lot of stuff here that was wrapped in their own prototypes, sometimes due to the needed packages not being commonJS compatible, other times for reasons(?). So right now what I got is this not really yahoo's fluxible state control, and a old version to boot, dependent a lot on mixins, which were deprecated in react, and while I've been chipping away at the problem I'm starting to think if I shouldn't just set it ablaze and redo the whole project from scratch; scavenging the components that can work with either Flux or Redux. My question is, try and keep upgrading the various components and tools -- I've already managed to make Reac-tIntl work without mixins, so that's one down, but who knows what's left, really-- or just go straight to redux or flux without legacy baggage?
|
|
#
?
Apr 5, 2017 18:08
|
|
|
Thanks for all the help from you dudes, this thread rules. I just landed a junior front end position, so I get to pretend I'm a real dev now!
|
|
#
?
Apr 5, 2017 19:49
|
|
|
I've got an issue with hover effects on the iPad. When the user touches the screen to scroll, it activates the hover state for the element that they've touched. Is there a way to change this behaviour? It looks ridiculous, and this is just one of MANY issues the iPad is giving us.
|
|
#
?
Apr 5, 2017 23:56
|
|
|
a hot gujju bhabhi posted:I've got an issue with hover effects on the iPad. When the user touches the screen to scroll, it activates the hover state for the element that they've touched. Is there a way to change this behaviour? It looks ridiculous, and this is just one of MANY issues the iPad is giving us. Don't use hover effects?
|
|
#
?
Apr 6, 2017 00:52
|
|
|
Gildiss posted:Don't use hover effects? That's ridiculous. The hover effects are for desktop, Android handles them correctly without an issue.
|
|
#
?
Apr 6, 2017 01:02
|
|
|
a hot gujju bhabhi posted:That's ridiculous. The hover effects are for desktop, Android handles them correctly without an issue. I think the idea was "use media queries to only have hover effects on desktop"? Hover effects aren't a thing on touch based devices 
|
|
#
?
Apr 6, 2017 01:41
|
|
|
Dogcow posted:I think the idea was "use media queries to only have hover effects on desktop"? Hover effects aren't a thing on touch based devices That's not what he said, had he said that it might have been helpful. And yes, I know hover effects aren't a thing on touch based devices which is why iOS shouldn't be registering them when you try to scroll. Thanks, I'll go with the media query approach, it's as close to a solution as I'll find I think  Edit: Actually even that isn't going to work, since there's no way to specifically target "desktop" it's just based off of resolution. putin is a cunt fucked around with this message at 04:37 on Apr 6, 2017 |
|
#
?
Apr 6, 2017 04:34
|
|
|
a hot gujju bhabhi posted:That's not what he said, had he said that it might have been helpful. And yes, I know hover effects aren't a thing on touch based devices which is why iOS shouldn't be registering them when you try to scroll. Thanks, I'll go with the media query approach, it's as close to a solution as I'll find I think Modernizr or something similar can tell you if you're on a tablet.
|
|
#
?
Apr 6, 2017 05:59
|
|
|
HaB posted:Modernizr or something similar can tell you if you're on a tablet. Some variation of this. Just Googling your question will turn up a trove of problems and solutions at StackOverflow: http://stackoverflow.com/questions/4817029/whats-the-best-way-to-detect-a-touch-screen-device-using-javascript The sane way of detecting if X is supported or conversely X is not supported, is to wrap an actual use of X in a try/catch and set a boolean depending on whether or not it gets caught. The devil lies in trying to detect every use case, so you need to determine where to draw the line, ie. "no I don't give a poo poo if Windows Phone doesn't register because our analytics says that's .001% of our user base and is not officially supported".
|
|
#
?
Apr 6, 2017 12:54
|
|
|
The issue comes from (I believe).. iPhone came out, and supported the whole web (well sans-flash) and since a lot of UI depended on :hover, they treated :focus like :hover. I believe Android did the same thing, but as websites started getting designed for touch, Android went the expected behavior of :focus being :focus. Apple has yet to update iOS Webkit to the expected behavior and maybe never will for fear of 'breaking the Internet' like when IE finally went more in line with standards.
|
|
#
?
Apr 6, 2017 14:07
|
|
|
Dealing with trying to make a React-Redux component that needed to validate and format inputs and outputs on a form has taught me to leverage tech that already exists instead of trying to reinvent the wheel. Why are we rolling our own validation poo poo instead of just using Redux-Form, whyyyyyy  This is my poor coworker's first exposure to front-end and she totally hates it. I kinda have to agree with her, at least with what we've got to work with.
|
|
#
?
Apr 6, 2017 14:17
|
|
|
Pollyanna posted:Dealing with trying to make a React-Redux component that needed to validate and format inputs and outputs on a form has taught me to leverage tech that already exists instead of trying to reinvent the wheel. Why are we rolling our own validation poo poo instead of just using Redux-Form, whyyyyyy We built a dynamic form builder with custom validation instead of just using Redux-Form,  Though I will admit that the form builder is pretty sweet now that we're at the other side of it. We can now build an admin panel for the business units to create new forms instead of developing each one from scratch
|
|
#
?
Apr 6, 2017 15:57
|
|
|
aBagorn posted:We built a dynamic form builder with custom validation instead of just using Redux-Form, The difference is that you're competent. We are not.
|
|
#
?
Apr 6, 2017 16:20
|
|
|
I dont like redux-form.
|
|
#
?
Apr 6, 2017 16:43
|
|
|
I guess I'm not experienced enough to know what the right call was, then. What should I have done, if I somehow ended up going back through time to the start?
Pollyanna fucked around with this message at 17:20 on Apr 6, 2017 |
|
#
?
Apr 6, 2017 16:59
|
|
|
Redux-form was probably what you should've used. I just don't like it...it feels half-assed, but I have a hard time putting my finger on what it is I don't like about it. I even use it from time to time, but I don't enjoy it.
|
|
#
?
Apr 6, 2017 17:14
|
|
|
e: my mistake ROFLburger fucked around with this message at 23:55 on Apr 6, 2017 |
|
#
?
Apr 6, 2017 23:36
|
|
|
ROFLburger posted:What about Redux-Form feels "half assed" to you? Me saying that I have a hard time putting my finger on what it is I don't like about it is what feels half-assed, not that redux-form feels half-assed.
|
|
#
?
Apr 6, 2017 23:50
|
|
|
Ugh, we have a handful of apps, most use React Router 3, but one uses 2 and another uses 4. Keeping track of which API is which is a serious pain in the dick.
|
|
#
?
Apr 6, 2017 23:56
|
|
|
Thermopyle posted:I dont like redux-form. I seemed to remember when we evaluated it, there were some logic quirks that required even more boilerplate at a time when we were on a crusade to reduce boilerplate. I don't care for it either. React Router is a dumpster fire of a project. Bumping major version to indicate breaking changes doesn't mean that you should completely change your API contracts every time. I don't really care for the documentation either. Now that I think about it, I don't like anything in this ecosystem. Time to jump back to non-front-end development 
|
|
#
?
Apr 7, 2017 00:05
|
|
|
aBagorn posted:We built a dynamic form builder with custom validation instead of just using Redux-Form, This is exactly what I'm working on at the moment. It's my first time with react and it feels like I'm basically jumping into the ocean with a massive riptide. Which is fun. Any major pitfalls that you encountered worth sharing?
|
|
#
?
Apr 7, 2017 00:30
|
|
|
Thermopyle posted:Redux-form was probably what you should've used. I just don't like it...it feels half-assed, but I have a hard time putting my finger on what it is I don't like about it. Helicity posted:I seemed to remember when we evaluated it, there were some logic quirks that required even more boilerplate at a time when we were on a crusade to reduce boilerplate. I don't care for it either. For me the whole react ecosystem feels off because it shits on the whole idea of react as a lightweight view library, and transforms it into a heavyweight web application framework shackled to a cornucopia of poorly thought out libraries a.k.a. "the ecosystem". The worst thing about react is, as usual, the people.
|
|
#
?
Apr 7, 2017 00:44
|
|
|
It's a framework without the benefit of opinionated development that frameworks usually give you. Yes, you are free to use Redux with any other view rendering library (but barely anyone does). Feel free to install CRA and/or React-redux-router-immutable-thunk-reselect-forms as the official*, blessed* bindings for that stack, but get hosed if you want to swap out any one of them because you have this crazy idea that a web app's vendor file shouldn't be 5mb.
|
|
#
?
Apr 7, 2017 01:56
|
|
|
Helicity posted:It's a framework without the benefit of opinionated development that frameworks usually give you. Yes, you are free to use Redux with any other view rendering library (but barely anyone does). Feel free to install CRA and/or React-redux-router-immutable-thunk-reselect-forms as the official*, blessed* bindings for that stack, but get hosed if you want to swap out any one of them because you have this crazy idea that a web app's vendor file shouldn't be 5mb. React is *not* a framework, and that's both a blessing and a curse. It's blessing because it's easy to learn, and so on, but modern front-end dev on large SPAs all but requires a framework, and there's nothing but a hodge-podge of crap that you mention that resembles one that uses React as it's view library. I'm of two minds on if this is a good thing (there are benefits to being able to pick your pieces) or a very bad thing (all that stuff you mention =) The concepts behind React + Redux are a great foundation for a framework to be built on. The problem is everyone is building their own and encountering the same pitfalls / reinventing the wheel. That said, I'm still a big fan of it, and think it is worth the hassles. Obviously not everyone needs to share that opinion.
|
|
#
?
Apr 7, 2017 15:34
|
|
|
What are thoughts on Polymer? With Google, Youtube, ING, Bloomberg, etc. using it, I'm intrigued.
|
|
#
?
Apr 7, 2017 16:19
|
|
|
So back to plain old JS or TS it is then?  I like ELM a lot, it is lightweight and the guy making it has a Vision of how it should work. I like that in software.
|
|
#
?
Apr 7, 2017 17:30
|
|
|
Mr Shiny Pants posted:So back to plain old JS or TS it is then? I *love* Elm as well. In fact, I finished my first toy project in it: https://www.eskimospy.com/chordbook (source is linked in the footer) No idea what I'm doing in it yet, and it has the "not a framework" problems as React+Redux I think, as well as "Oh, I have to write JS anyway with a port since Elm doesn't do that" problems, but it's fun to write!
|
|
#
?
Apr 7, 2017 19:41
|
|
|
COOL CORN posted:What are thoughts on Polymer? With Google, Youtube, ING, Bloomberg, etc. using it, I'm intrigued. The dogs balls. I really love it, waiting for 2.0 to get out of RC for that ECMAScripr 6 class goodness.
|
|
#
?
Apr 8, 2017 02:49
|
|
|
Lumpy posted:I *love* Elm as well. In fact, I finished my first toy project in it: https://www.eskimospy.com/chordbook (source is linked in the footer) The need for ports should become less and less as the community gets bigger and the core stabilizes. Otherwise I agree with you.
|
|
#
?
Apr 8, 2017 11:04
|
|
|
Lumpy posted:React is *not* a framework, and that's both a blessing and a curse. It's blessing because it's easy to learn, and so on, but modern front-end dev on large SPAs all but requires a framework, and there's nothing but a hodge-podge of crap that you mention that resembles one that uses React as it's view library. I'm of two minds on if this is a good thing (there are benefits to being able to pick your pieces) or a very bad thing (all that stuff you mention =) 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.
|
|
#
?
Apr 9, 2017 01:53
|
|
|
|
| # ? Jun 6, 2024 15:10 |
|
|
One attempt I've seen but not played with is https://zeit.co/blog/next2
|
|
#
?
Apr 9, 2017 03:23
|
|
