|
e: nvm im just dumb streetlamp fucked around with this message at 06:11 on Aug 22, 2015 |
#
?
Aug 14, 2015 02:13
|
|
|
|
| # ? Apr 27, 2024 01:51 |
|
|
It's been out for a while and yet no-one's talking about Relay. Could it be because it's actually surprisingly complicated? I was a bit overwhelmed by all the moving parts, so I made an interactive diagram of how it all fits together for visually minded people like me: http://sgwilym.github.io/relay-visual-learners/
|
|
#
?
Aug 22, 2015 14:39
|
|
|
WORLDS BEST BABY posted:It's been out for a while and yet no-one's talking about Relay. Could it be because it's actually surprisingly complicated? I was a bit overwhelmed by all the moving parts, so I made an interactive diagram of how it all fits together for visually minded people like me: http://sgwilym.github.io/relay-visual-learners/ Very cool page, thanks. I didn't know about this. I'm guessing you made it with Relay? But I'm wondering what advantage this has over Angular? From what I see every view now depends on GraphQL in the front-end and back-end resolving a "query" when you route, and it still depends on React components. Lack of flexibility and ability to work directly with the DOM is the reason I don't use React, but I'm always ready to be convinced otherwise. I'm not seeing how this added complexity does anything for me, except maybe add more organization in my code.
|
|
#
?
Aug 23, 2015 16:56
|
|
|
pepito sanchez posted:Very cool page, thanks. I didn't know about this. I'm guessing you made it with Relay? Nah, this is just a React app as all the information on the page is static (Relay is a data fetching framework - no views whatsoever). I think one of the biggest benefits of React is that you don't touch the DOM directly. React components are just functions that take props (immutable arguments) and render a view. This makes them more predictable, easy to debug, and composable (your components can easily be mixed and nested within others — really flexible!). But because React components are composable and nested, you end up having to write a lot of ajax or a lot of custom endpoints to get data from the server in the shape that you need it in, meaning that every change you make to your view's data requirements you'd need to make changes on the server too, which sucks. Or just always be sending a giant blob of data, half of which you don't use, which sucks. Or make separate requests for every bit of data you need, which sucks. So I'd say the main draw of Relay is that the client specifies the shape of the data that your views need, and GraphQL is the layer that makes sure the requests are valid and does all the work of assembling that data. Now instead of your React components just hoping they'll get the data they depend on from your server (and a whole lot of your own data fetching code in between), you can put them in containers that specify for instance that what they need is a User with ID 123 and, in this case, only the name and age fields. GraphQL validates and executes the request, and returns only the data your React components need. It's trying to for data what React does for views: make it declarative, consistent and composable. But yes, I hope the API will become a little more simplified. I'm probably butchering this though — this talk should be able to explain the benefits much better than I can: https://www.youtube.com/watch?v=IrgHurBjQbg WORLDS BEST BABY fucked around with this message at 22:03 on Aug 23, 2015 |
|
#
?
Aug 23, 2015 21:55
|
|
|
Also, it's not true that you can't work directly with the DOM in React, just that you need to exercise proper care whilst doing so (which you need to do anyway, regardless of what framework/library you're in). Add a componentDidMount function and you can access the DOM of a component no worries, so you can bind more detailed behaviours such as drag and drop or whatever.
|
|
#
?
Aug 23, 2015 23:44
|
|
|
thanks for the clarification! and i didn't say react can't work with the DOM, just that is has limited ability compared to Angular. Directives are really nice once you get the hang of it. obviously any JS can work directly with the DOM. i get it a little better now, and i'm looking forward to seeing how this progresses.
|
|
#
?
Aug 24, 2015 04:22
|
|
|
The DOM is horrible and working with it is horrible - I'm not sure why it's desirable to anyone in 2015, but to each their own.
|
|
#
?
Aug 24, 2015 04:28
|
|
|
Helicity posted:The DOM is horrible and working with it is horrible - I'm not sure why it's desirable to anyone in 2015, but to each their own. why?
|
|
#
?
Aug 24, 2015 04:43
|
|
|
Helicity posted:The DOM is horrible and working with it is horrible - I'm not sure why it's desirable to anyone in 2015, but to each their own. yes it is. the DOM is a horrible thing that we all have to deal with. that's why i rather <html><body><div doMyCodePls> than having to work with it any more directly. react has its own answer, like any front-end framework, but it just grows in complexity. same goes for templating. i really think of it as having to learn how to love your enemy with Angular. other frameworks try to do it better, and i actually started with backbone and marionette, but for me personally there hasn't been something that feels as complete, refined, and mature, even despite the switches needed for angular 2.0. that's why i'm learning typescript in the first place. like i said i'm always ready to be convinced otherwise. relay looks cool, but react is lacking imho.
|
|
#
?
Aug 24, 2015 04:51
|
|
|
gbaby posted:why? p much any crockford speech. even if he is a retard he made a good point there. the dom is a stupid, terrible thing. e: https://www.youtube.com/watch?v=Y2Y0U-2qJMs also why the 70+ minutes video wouldn't be justified in a post pepito sanchez fucked around with this message at 04:55 on Aug 24, 2015 |
|
#
?
Aug 24, 2015 04:53
|
|
|
I dunno, working with the DOM post IE8 isn't too bad. What is hard is maintaining a consistent UI with constantly changing Data, which is basically why we have frameworks & libraries to turn data into a DOM representation. It's kind of confusing to me that you find Angular directives better for this than React components, if there's one thing React is really loving good at its isolating complexity in the UI.
|
|
#
?
Aug 24, 2015 10:40
|
|
|
gbaby posted:why? DOM3 is 11 years old, and how we use Javascript, and even the web, has changed quite a bit since then. Probably the worst thing about it is that every browser has implemented it differently. That there was an almost ubiquitous need for an API on top of the DOM like jQuery is the best evidence that it was broken. Although things have gotten better for small sites that only need to support modern browsers, large sites can't just say "gently caress off" to IE9 users (yet). Even with new features being discussed in 2015, we have Safari lagging behind, Mozilla/Google fighting among themselves and implementing things differently. A portion of the toolchain hell that is commonly lamented about in here is directly trying to workaround limitations of the DOM. edit: GraphQL chat - a ton of my work is building/maintaining a broad variety of APIs, so I'm starting to poke around and see if it could solve any of my problems without introducing other ones that are worse. That's not really a topic for front-end dev chat, but I'd be interested in hearing others' experiences with it. luchadornado fucked around with this message at 15:21 on Aug 24, 2015 |
|
#
?
Aug 24, 2015 15:17
|
|
|
Helicity posted:edit: GraphQL chat - a ton of my work is building/maintaining a broad variety of APIs, so I'm starting to poke around and see if it could solve any of my problems without introducing other ones that are worse. That's not really a topic for front-end dev chat, but I'd be interested in hearing others' experiences with it. Without going off on too much a tangent, I've been working on a GraphQL branch of a Rails API with graphql-ruby and it’s been extremely straightforward — maybe taken three days tops. It's been wonderful to throw out each model’s controller and replace it with a single queries controller. I can really see GraphQL's documentation features (names, descriptions, deprecation information as a part of your schema) coming in really handy too.
|
|
#
?
Aug 24, 2015 16:35
|
|
|
Helicity posted:DOM3 is 11 years old, and how we use Javascript, and even the web, has changed quite a bit since then. Probably the worst thing about it is that every browser has implemented it differently. That there was an almost ubiquitous need for an API on top of the DOM like jQuery is the best evidence that it was broken. Although things have gotten better for small sites that only need to support modern browsers, large sites can't just say "gently caress off" to IE9 users (yet). Even with new features being discussed in 2015, we have Safari lagging behind, Mozilla/Google fighting among themselves and implementing things differently. A portion of the toolchain hell that is commonly lamented about in here is directly trying to workaround limitations of the DOM. JQuery isn't useful past IE8 or so. It's a frankenstein monster consisting of a) A really hosed up event handling normalization library that made sense when you needed to support both IE8 and Chrome but is now slow as poo poo b) JQuery selectors, which are great for writing horrible monkey patches if you're too lazy to put ids and classes on the elements you create. c) A half-baked promise library that works really well as long as nothing throws an exception but is otherwise functional. Hands down the best thing in the JQuery library. d) A wrapper for XHR that again made sense when you used to support IE7 but now is only useful because of JQuery's aforementioned half-baked promise library. e) A bunch of functions that mirror exactly vanilla JS functions except it's in JQuery.
|
|
#
?
Aug 26, 2015 13:07
|
|
|
Can we talk about replacements, then?
|
|
#
?
Aug 26, 2015 13:12
|
|
|
Bruegels Fuckbooks posted:JQuery isn't useful past IE8 or so. It's a frankenstein monster consisting of That spells out why the DOM and ECMAScript was horrible and why we needed jQuery for so long, and I doubt anyone will disagree with you on those points. The lovely part is, and maybe I'm in the minority here with the type of sites I work on, but we were finally able to drop IE8 support in 2014. We *might* be able to drop IE9 support this year. There may only be 10% of users on IE9 for a large site but that could easily be millions of uniques every month, and that's $$$. Even then, I can't just take jQuery out of a site without a massive rewrite - there are tool tips and timers and UI sliders and all sorts of stupid poo poo that rely on it. So yeah, I consider jQuery a relic at this point and while it made life easy for me several years ago, I haven't included it on any small/personal sites for the last 2-3 years. I mentioned it as an example of how even a library with its faults could still be included on pretty much every web site in the late 2000s because it provided some very useful functionality while DOM/ECMAScript basically stagnated for several years. Blinkz0rz posted:Can we talk about replacements, then? This is a good start: http://youmightnotneedjquery.com/ luchadornado fucked around with this message at 13:28 on Aug 26, 2015 |
|
#
?
Aug 26, 2015 13:25
|
|
|
I still use jQuery because it makes convenient and consistent shorthands for funcs I use all the time. $('.poop').on('click', fart); vs var poops = document.querySelectorAll('.poop'); for(var i=0; i < poops.length; i++){ poops[i].addEventListener('click', fart); } I almost didnt even type out all the second one bc i'm on phone and it was so much to type. Of course there could be a library out there that already handles these shorthands without being bloated, but my point is jQuery already makes this quick to type which imo is actually really important.
|
|
#
?
Aug 27, 2015 15:54
|
|
|
jquery needs to put out a lite version for just the selectors, cause gently caress typing all that 
|
|
#
?
Aug 27, 2015 16:24
|
|
|
kloa posted:jquery needs to put out a lite version for just the selectors, cause gently caress typing all that my favourite part is that it's only because nodelist doesn't extend array, otherwise you could just one-line it document.querySelectorAll('.poop').forEach(function(p){p.addEventListener('click', fart);}); e: mind you a lot of this stuff is simple and you could just write a tiny "dealing with loving nodelists" module. var fuckingNodeLists = require('dealing-with-loving-nodelists'); PlaneGuy fucked around with this message at 16:40 on Aug 27, 2015 |
|
#
?
Aug 27, 2015 16:38
|
|
|
If you aren't using call/apply when appropriate, you're missing out on useful Javascript functions: Array.prototype.forEach.call(document.getElementsByClassName('poop'), function(el) { console.log(el.tagName); }); edit: if you're curious why NodeList isn't an array and you have to resort to silliness: https://esdiscuss.org/topic/why-does-legacy-content-break-when-making-array-likes-real-arrays luchadornado fucked around with this message at 16:53 on Aug 27, 2015 |
|
#
?
Aug 27, 2015 16:48
|
|
|
obstipator posted:I still use jQuery because it makes convenient and consistent shorthands for funcs I use all the time. It really depends on if you care about performance and event listener leaks. Most of the time you probably don't. But if you use the JQuery event handling, there's a whole bunch of bullshit code that does event normalization - like, in a mousemove handler, I've seen JQuery take 30% CPU time just doing event normalization (JQuery.fix()), just so the event will look the same (sort of) in IE8 as it does in Chrome or Firefox. Another problem is that if you leak a regular event handler (like say you attach an event handler to an element and remove the element) - with regular event handlers, it goes away. With JQuery, JQuery has its own layer that holds references to whatever JQuery event handlers are assigned, and that layer will keep a reference to the element that was removed, and it'll never garbage collect and you're hosed. Similarly, if you use like $.proxy instead of .bind(this), you can get screwed because since JQuery implemented keeping the scope in the library, whatever scope you're holding will just stick around and not garbage collect. So in short it's really easy to get hosed when writing long running single page apps using JQuery. It's not impossible to use if you're disciplined but JQuery has wasted a lot of my time in my front end career so far.
|
|
#
?
Aug 28, 2015 13:19
|
|
|
How good are the Egghead.io tutorials for learning React/Flux? I've been wanting to create a small site as a personal project using React and have been having a tough time finding good resources.
|
|
#
?
Aug 31, 2015 20:49
|
|
|
Ochowie posted:How good are the Egghead.io tutorials for learning React/Flux? I've been wanting to create a small site as a personal project using React and have been having a tough time finding good resources. i can't say how good they are for React/Flux, but if it means anything at all their tutorials for Angular were the best i've seen around. if i wanted to learn a new JS library or framework i'd probably look at them before anyone else.
|
|
#
?
Aug 31, 2015 21:48
|
|
|
Ochowie posted:How good are the Egghead.io tutorials for learning React/Flux? I've been wanting to create a small site as a personal project using React and have been having a tough time finding good resources. I seem to remember when I was just getting started with React using Egghead.io. I'm now a mediocre React developer. That's more to do with me being a mediocre developer than Egghead.io being a mediocre resource!
|
|
#
?
Aug 31, 2015 21:52
|
|
|
kloa posted:jquery needs to put out a lite version for just the selectors, cause gently caress typing all that https://github.com/bendc/sprint
|
|
#
?
Aug 31, 2015 22:41
|
|
|
So I've been learning Ember for my job and I'm not really sure how to approach this problem with it, anyone here know how to use it? Basically I'm making a one screen app, basically just google maps with a sidebar you can do things on. So I have this map in the middle with a bunch of points on it, you can select one of the points at a time, and a sidebar on the left, and I want to have a button on the sidebar that retrieves information from a server for the point that you've selected. I can see just having an action handler on the button which sends an action up to the route which fires off an ajax call and hands down the information again, but the guides push heavily towards Ember Data and the router and I'm not really sure how to use those effectively. Should I be making the button click link to a nested route that will retrieve the information on the point from the store (and then the server) and display it on the same page? I can see doing this if clicking the button meant going to a whole new page but it seems kind of odd when it's just filling out a piece of information on the same screen. If I have five buttons will I have five nested routes and each button should just link to the corresponding nested route?
|
|
#
?
Sep 2, 2015 00:55
|
|
|
does anyone here use typescript, and happen to use angular too? i'm trying to get an angular constant from a module into a service, but typescript complains if i try this: service module: code:code:
|
|
#
?
Sep 2, 2015 20:14
|
|
|
I don't really know typescript but it looks like you need to inject appSettings into ProductAccessService. at least that's how you'd do it in plain angular:code:
|
|
#
?
Sep 2, 2015 20:41
|
|
|
i tried that. and just tried it again with a few changes. what i posted is a basic "i want this angular thing to work in my typescript thing". it's a bit frustrating. it's always the same "cannot find 'appSettings'.any" error, unless I try initializing appSetting as a const outside of the service and interface codeblocks, but that transpiles into a var, which is not what i want at all. i want access to a normal .constant() in either the the productAccessService module or any other module i feel like using. i did already try moving the constant to the end of the productAcessService module instead.
|
|
#
?
Sep 2, 2015 21:02
|
|
|
pepito sanchez posted:i tried that. and just tried it again with a few changes. what i posted is a basic "i want this angular thing to work in my typescript thing". it's a bit frustrating. it's always the same "cannot find 'appSettings'.any" error, unless I try initializing appSetting as a const outside of the service and interface codeblocks, but that transpiles into a var, which is not what i want at all. i want access to a normal .constant() in either the the productAccessService module or any other module i feel like using. i did already try moving the constant to the end of the productAcessService module instead. This is a config service I'm using that does just that. However, what you may not be taking into account is how you populate that constant. If it is populated via some $http call, it's likely you are trying to fetch & use the constant before the http call returns. If that is the case, you need to do one of two things. 1. Wrap all calls to use the constant in promises all the way down, or 2. Load the config first, populate it in Angular, THEN bootstrap your application. code:
|
|
#
?
Sep 2, 2015 21:12
|
|
|
^^^^ Right, i'll have to do something like that. Somehow a constant falls under ng.IModule, because this fixed it, but it's like a bandaid for now: code:code:
|
|
#
?
Sep 2, 2015 21:17
|
|
|
pepito sanchez posted:
Shouldn't need to use IModule... Typescript doesn't care what you type your injected services to, as the types all go out the window when compiled anyways.
|
|
#
?
Sep 2, 2015 21:22
|
|
|
Skandranon posted:Shouldn't need to use IModule... Typescript doesn't care what you type your injected services to, as the types all go out the window when compiled anyways. you're right again. i could just put it as any and it still compiles the same.
|
|
#
?
Sep 2, 2015 21:24
|
|
|
Here is a snippet which will define your Angular module, load up some json file, set it as your constant, THEN bootstrap your application.code:Skandranon fucked around with this message at 21:35 on Sep 2, 2015 |
|
#
?
Sep 2, 2015 21:31
|
|
|
Have you ever hit a wall with learning a general concept so hard that it's caused you to contemplate if you've picked the wrong career path, despite months of investment trying to learn the general framework? This is how I feel when it comes to methods. I have this challenge in my Thinkful course where i'm supposed to build the function for this 'Hot or Cold' game app in order to get it to work, connecting the already built HTML/CSS to bring these static files to life. Despite spending the weekend trying to wrap my head around all the new terminology and working my way through the example exercises, I was still nowhere close to figuring out how to build this thing outside of the general 'function newGame () { }' frame. I caved and found the correct answer through this codepen online, but i'll be damned on how I was supposed to put this together myself. Here's the correct answer for those interested: code:Had to spend a good chunk of today trying to figure out what half of that stuff even is, much less what's causing what to go where and do what in the app. Maybe someone could break this function down in layman's terms so I can better grasp what's going on in this thing? I tend to learn better by reverse engineering the finished solution in order to wrap my head around it, and i'm pretty burnt out already :? White Light fucked around with this message at 02:49 on Sep 3, 2015 |
|
#
?
Sep 3, 2015 02:44
|
|
|
Parrotine posted:Have you ever hit a wall with learning a general concept so hard that it's caused you to contemplate if you've picked the wrong career path, despite months of investment trying to learn the general framework? Are you asking how it gets hooked up to the application at large? Or just how this function works? Math.floor() removes any decimals. Math.random() creates a random number between 0-1. Multiplying by 100 and removing decimals gets you a random number between 0 and 99. randomNumber.check() is a function which when passed in a number, will check against the generated number. Not sure why it works in general though, it doesn't make a lot of sense, a more sensible function would be code:Skandranon fucked around with this message at 03:25 on Sep 3, 2015 |
|
#
?
Sep 3, 2015 03:21
|
|
|
Parrotine posted:Have you ever hit a wall with learning a general concept so hard that it's caused you to contemplate if you've picked the wrong career path, despite months of investment trying to learn the general framework? You gotta relax, programming is actually pretty hard to get in to and it's one of those things that just seems easy looking back on it. JavaScript can also be pretty odd since it's incredibly fluid and loose, so you can do things that you wouldn't be able to do in other languages like just attach properties on to any object. A lot of stuff in Java would probably just result in the compiler shouting at you until you change it, while in JS anything goes until you run the line that has an actual issue.
|
|
#
?
Sep 3, 2015 03:53
|
|
|
One of the major potential benefits I can think of that using TypeScript might offer, would be an IDE being capable of using decent Intellisense and 'instant' error checking (so if you type the wrong property name, you find out right away thanks to a red line or something). Is there an IDE that supports this? Please keep in mind I've never actually tried TypeScript.
|
|
#
?
Sep 3, 2015 08:43
|
|
|
Parrotine posted:Have you ever hit a wall with learning a general concept so hard that it's caused you to contemplate if you've picked the wrong career path, despite months of investment trying to learn the general framework? Skandranon posted:Are you asking how it gets hooked up to the application at large? Or just how this function works? Math.floor() removes any decimals. Math.random() creates a random number between 0-1. Multiplying by 100 and removing decimals gets you a random number between 0 and 99. randomNumber.check() is a function which when passed in a number, will check against the generated number. Not sure why it works in general though, it doesn't make a lot of sense, a more sensible function would be The original version doesn't make sense to me. It has an inner function that is never called so the outer function doesn't return anything. Also, randomNumber.number would be undefined in the original version wouldn't it? I know javascript is hosed up but I don't think Math.floor adds a number property to randomNumber silently. Your version makes sense except it still doesn't return anything from newGame().
|
|
#
?
Sep 3, 2015 09:04
|
|
|
|
| # ? Apr 27, 2024 01:51 |
|
|
The Wizard of Poz posted:One of the major potential benefits I can think of that using TypeScript might offer, would be an IDE being capable of using decent Intellisense and 'instant' error checking (so if you type the wrong property name, you find out right away thanks to a red line or something). Is there an IDE that supports this? Please keep in mind I've never actually tried TypeScript. Microsoft Visual Studio 2013.
|
|
#
?
Sep 3, 2015 10:59
|
|