|
For automagical stuff, things like redux-pouchdb-plus are kind of cool. PouchDB itself is a JS database implementation that saves stuff local in the browser via IndexedDB or WebSQL and auto-syncs from a CouchDB instance on the web, and then the Redux integration automatically generates/updates your state from that, so the end result is that your state automatically populates from whatever CouchDB setup you have and you have to give minimal worry to handling offline usage, etc.Newf posted:by that, I mean, I hope, user authored React Components. Do keep in mind that this is ultimately the same as letting random people put arbitrary code into your app. Roadie fucked around with this message at 09:48 on Apr 16, 2017 |
#
?
Apr 16, 2017 09:45
|
|
|
|
| # ? Apr 25, 2024 20:50 |
|
|
Roadie posted:For automagical stuff, things like redux-pouchdb-plus are kind of cool. PouchDB itself is a JS database implementation that saves stuff local in the browser via IndexedDB or WebSQL and auto-syncs from a CouchDB instance on the web, and then the Redux integration automatically generates/updates your state from that, so the end result is that your state automatically populates from whatever CouchDB setup you have and you have to give minimal worry to handling offline usage, etc. This is cool, thanks. Another requirement of my project is that it's offline-first. I've been fiddling with pouchdb, but I hadn't come across this integration with redux. Roadie posted:Do keep in mind that this is ultimately the same as letting random people put arbitrary code into your app. Really gets to the spirit of npm development, eh? But seriously, yes, this is a problem. My fuzzy idea is to sandbox the user-made code and allow it to pass its info back to the app only via injected components authored by me.
|
|
#
?
Apr 16, 2017 18:08
|
|
|
Unrelated VSCode question. I've got the following launch.json for a project:JavaScript code:Running pre:node .\bin\lynda-copy-course.ts .\testData\source .\testData\dest pre:node .\bin\lynda-copy-course.js .\testData\source .\testData\dest Is VSCode inferring the location of the compiled version of this typescript file, and using that?
|
|
#
?
Apr 16, 2017 18:28
|
|
|
Hey dudes. Question about this official Redux vid describing how to deal with JS data structures immutably, since that's a requirement of Redux reducer funcs. Why not just lodash deepCopy your state as the first step, and do what you see fit with it before returning? Seems cleaner and more flexible. Is there a performance reason to use concat, slice, spread, etc?
|
|
#
?
Apr 16, 2017 20:13
|
|
|
Dominoes posted:Hey dudes. Question about this official Redux vid describing how to deal with JS data structures immutably, since that's a requirement of Redux reducer funcs. If your app state is very small, it could be a viable approach. As it grows, you may run into performance issues, but in the spirit of not prematurely optimizing, give it a whirl and see how it behaves. If things get chunky, profile!
|
|
#
?
Apr 16, 2017 21:32
|
|
|
jQuery's documentation for the .html() method states:quote:When .html() is used to set an element's content, any content that was in that element is completely replaced by the new content. Is there any reason to do the following? code:I'm going to say no, but I wasn't sure if this is 'encouraged' to prevent any issues across browsers. About a year ago my company's flagship application was rewritten to be brought out of the dark ages to be on par with what you might expect out of a web application 10 years ago instead of 15  Looks like this year will be a slow year so I've just been going through everything and cleaning up all the garbage code written by the Indian code farm that churned this out. Finally finished with the server side code and now started the JS recently. I know it's only 1 line of code, but that's 1 extra live everywhere the software makes an ajax request... All adds up on the end. 12MB JS library, and any time we update the JS on the site users have to download the entire package 
|
|
#
?
Apr 17, 2017 13:17
|
|
|
Sab669 posted:
I'm guessing his thought was that if there was an error rendering someVar, you'd be left with a blank div instead of the previous content.
|
|
#
?
Apr 17, 2017 13:31
|
|
|
Kekekela posted:I'm guessing his thought was that if there was an error rendering someVar, you'd be left with a blank div instead of the previous content. A decent thought, but probably better ways to accomplish it.
|
|
#
?
Apr 17, 2017 20:00
|
|
|
porksmash posted:A decent thought, but probably better ways to accomplish it. Sab669 posted:Looks like this year will be a slow year so I've just been going through everything and cleaning up all the garbage code written by the Indian code farm that churned this out. Finally finished with the server side code and now started the JS recently. I know it's only 1 line of code, but that's 1 extra line everywhere the software makes an ajax request... All adds up on the end. 12MB JS library, and any time we update the JS on the site users have to download the entire package I'm going to go out on a limb here and say they didn't do anything the "better way".
|
|
#
?
Apr 17, 2017 20:23
|
|
|
Lumpy posted:I'm going to go out on a limb here and say they didn't do anything the "better way". Generally a safe bet when it comes to these guys. I'm just far less experienced with JS than I am C# so I wasn't certain if there was, as I said, any "best practices" going on here.
|
|
#
?
Apr 17, 2017 21:08
|
|
|
Dominoes posted:Why not just lodash deepCopy your state as the first step, and do what you see fit with it before returning? Seems cleaner and more flexible. Is there a performance reason to use concat, slice, spread, etc? _.deepCopy would be the most expensive possible way to go about doing that. though it isn't uncommon to return a whole new object using Object.assign and coalescing whatever new data into the old state if you have something more complex than a simple list.
|
|
#
?
Apr 17, 2017 23:59
|
|
|
If you want a reliable and efficient way to do immutability, you probably shouldn't look much farther than facebook's Immutable library. Redux's dev tools support it easily as well so you're not debugging weird constructs. Yes, you manually do concats and assigns and whatever, but that adds lots of line noise to your reducers that masks intent. IMO using immutable is far clearer and is not as vulnerable to making a mistake.
|
|
#
?
Apr 18, 2017 00:07
|
|
|
When I get to the point where I want to switch over to immutability from vanilla ES6 JS, I usually use seamless-immutable.
|
|
#
?
Apr 18, 2017 01:04
|
|
|
Can you guys explain what immutability really is and why someone wants something immutable (preferably with a use case)? It seems like a pretty easy concept but it really confuses me E: i guess i'm asking mainly about immutable state. Why would you want state to be immutable? teen phone cutie fucked around with this message at 05:20 on Apr 18, 2017 |
|
#
?
Apr 18, 2017 04:14
|
|
|
Grump posted:Can you guys explain what immutability really is and why someone wants something immutable (preferably with a use case)? Something being immutable in programming just means once it's set it can't be changed. In Javascript things like strings and numbers are by design immutable, the only way to change them is to make new ones. Arrays and lists are not immutable in Javascript though. There are lots of reasons why you would or wouldn't want something to be mutable. There are performance and coding challenges with either approach, immutable data structures are popular with functional programming but object oriented languages certainly can do it too. A google search brought up a few articles that do a good job of explaining it, this one is nice and uses Javascript as an example. https://www.sitepoint.com/immutability-javascript/
|
|
#
?
Apr 18, 2017 04:40
|
|
|
Grump posted:Can you guys explain what immutability really is and why someone wants something immutable (preferably with a use case)? As a use case, immutability is very useful in a redux & react architecture because it means the UI can be updated efficiently. The two main properties of immutability that allows this are: - structural sharing  Here's a diagram where lets say a map called 'xs' gets an update, it added a new thing called 'e' as a child of 'f'. With good immutable structures, you can set that update and the data structure will REUSE anything that doesn't need to change, so in this case the new 'ys' map still retains a reference to 'b', and the new 'g`' retains a reference to 'h'. This means each new copy isn't nearly as expensive memory wise, because only the bits that need to change are changed. This also means you have... - guaranteed referential equality as a byproduct The UI can verify whether it needs to render new information based on these immutable structures. Because of structural sharing and the immutable guarantee, the UI can be absolutely sure that if it was given a property and that property === the last property it was given, then it doesn't need to rerender. Big React apps leverage this an awful lot with PureComponent (https://facebook.github.io/react/docs/react-api.html#react.purecomponent)
|
|
#
?
Apr 18, 2017 05:19
|
|
|
Maluco Marinero posted:As a use case, immutability is very useful in a redux & react architecture because it means the UI can be updated efficiently. The two main properties of immutability that allows this are: So in that diagram, what is immutable there? it seems like the entirety of 'xs' is very mutable.
|
|
#
?
Apr 18, 2017 06:04
|
|
|
Grump posted:So in that diagram, what is immutable there? it seems like the entirety of 'xs' is very mutable. Everything in 'xs' is immutable, 'ys' is the changed/updated stuff. ElCondemn fucked around with this message at 06:12 on Apr 18, 2017 |
|
#
?
Apr 18, 2017 06:09
|
|
|
Grump posted:So in that diagram, what is immutable there? it seems like the entirety of 'xs' is very mutable. No, 'xs' hasn't changed and anything that still has references to 'xs' can count on it being completely unchanged. 'ys' is a totally new object which just has references to parts of 'xs's tree, the parts that didn't need to be changed in order to insert 'e' into the tree. The diagram is trying to say that when they do the change (in blue), new objects are created to reflect that change rather than mutation of the old data (in black).
|
|
#
?
Apr 18, 2017 06:11
|
|
|
Okay. Thanks for that. I don't know why that concept was giving me so much trouble. I still have trouble when it comes to using the ES6 keywords like let and const correctly, but I think this will definitely help a bit.
|
|
#
?
Apr 18, 2017 12:56
|
|
|
Sab669 posted:jQuery's documentation for the .html() method states: IIRC that's a speed optimization that prevents an extra layout update?... somehow? I was never clear on how and it didn't seem worth the extra code for how little it happened in the project I was working on at the time, but it was recommended style.
|
|
#
?
Apr 18, 2017 16:23
|
|
|
Grump posted:Why would you want state to be immutable? One of the big benefits Like Maluco said, is that you can do reference comparisons (is this new state object just the same reference as the old state object?) as opposed to some kind of enumerated equality comparison (does this new state object have all of the same members, with the same values as the old state object did?) which is a ton faster
|
|
#
?
Apr 18, 2017 16:49
|
|
|
ROFLburger posted:One of the big benefits Like Maluco said, is that you can do reference comparisons (is this new state object just the same reference as the old state object?) as opposed to some kind of enumerated equality comparison (does this new state object have all of the same members, with the same values as the old state object did?) which is a ton faster Could you give me like a pseudocode example?
|
|
#
?
Apr 18, 2017 23:43
|
|
|
Grump posted:Could you give me like a pseudocode example? If you have a view with a list of 10,000 forum posts and you just clicked the "heart" on one, you just changed your app state. Using an immutable library means: A, that the update is faster because it will reuse 9,999 objects and B, that the checks to see if each individual post component has to re-render is fast because you can do a "cheap" equality check.
|
|
#
?
Apr 19, 2017 00:14
|
|
|
Lumpy posted:If you have a view with a list of 10,000 forum posts and you just clicked the "heart" on one, you just changed your app state. Using an immutable library means: A, that the update is faster because it will reuse 9,999 objects and B, that the checks to see if each individual post component has to re-render is fast because you can do a "cheap" equality check. I'm not sure it's faster... toggling a boolean in an existing structure has to be as fast as things get. The problem then becomes "what part of this 10k thing changed", which is not obvious. Immutability makes the 2nd problem trivial and fast, but complicates the first part.
|
|
#
?
Apr 19, 2017 00:18
|
|
|
okay. I think I'm making this seem more confusing than it is. So if I have my state as something like: { timestamp: Jan 2nd, liked: 0 } and then make a new variable and set it equal to mapping over the old state and changing the 'liked' to 1. And then set the state equal to my new variable Nothing was mutated here. I just used the old state in my new variable and then updated the state?
|
|
#
?
Apr 19, 2017 02:56
|
|
|
Skandranon posted:I'm not sure it's faster... toggling a boolean in an existing structure has to be as fast as things get. The problem then becomes "what part of this 10k thing changed", which is not obvious. Immutability makes the 2nd problem trivial and fast, but complicates the first part. Mutating an existing structure is faster, sure. It was my understanding (which may be incorrect) that when you used Object.assign or spread syntax to change big things Imutable was faster. Grump posted:okay. I think I'm making this seem more confusing than it is. Watch this video: https://m.youtube.com/watch?v=I7IdS-PbEgI
|
|
#
?
Apr 19, 2017 04:08
|
|
|
Lumpy posted:Mutating an existing structure is faster, sure. It was my understanding (which may be incorrect) that when you used Object.assign or spread syntax to change big things Imutable was faster. Object.assign may be faster than instantiating your own object, but any time you create a new object, it's more expensive than mutating an existing object. The value of immutable data structures is it can make OTHER problems faster, like DOM change detection, which often is a worthwhile tradeoff, as creating/destroying DOM elements are vastly more expensive than creating/destroying JavaScript objects in memory.
|
|
#
?
Apr 19, 2017 05:36
|
|
|
The key takeaway about immutability is that it allows you to reason through operations on data structures very easily. Code becomes cleaner and easier to read and you avoid situations like with Array.sort where the returned value and the input value are both sorted.
|
|
#
?
Apr 20, 2017 11:35
|
|
|
The more I get into ES6 and typescript the more I get iffy about using the super() keyword in Javascript. I came from a Java and C# background and part of the reason why I wanted a change of pace was because I was getting tired of class inheritance programming, also because I kinda hated programming in Eclipse, but whenever I see a recent-ish "how to do x in react" article there's always classes. So are ES6 classes nothing but syntax sugar and should I just get used to them, because they're here to stay, and somehow keep reminding myself that Java/C# classes aren't the same as JS?
|
|
#
?
Apr 20, 2017 11:53
|
|
|
Honest Thief posted:The more I get into ES6 and typescript the more I get iffy about using the super() keyword in Javascript. I came from a Java and C# background and part of the reason why I wanted a change of pace was because I was getting tired of class inheritance programming, also because I kinda hated programming in Eclipse, but whenever I see a recent-ish "how to do x in react" article there's always classes.
|
|
#
?
Apr 20, 2017 12:28
|
|
|
Well, to a degree yes you have inheritance because the React components require a standard interface to know how to render, but you're much more likely to be composing smaller components rather than writing monster inheritance chains. You can also write pure functions if they don't have any state or methods, so they essentially become a React component with only a render function and no state. While classes are involved, most libraries and codebases I've seen are all about composition rather than inheritance.
|
|
#
?
Apr 20, 2017 13:10
|
|
|
Honest Thief posted:The more I get into ES6 and typescript the more I get iffy about using the super() keyword in Javascript. I came from a Java and C# background and part of the reason why I wanted a change of pace was because I was getting tired of class inheritance programming, also because I kinda hated programming in Eclipse, but whenever I see a recent-ish "how to do x in react" article there's always classes. Well I mean, if you have to compare old school js prototype inheritance - which is essentially just pointers to methods - versus having legit subclass polymorphism and interfaces available in the language...
|
|
#
?
Apr 20, 2017 13:36
|
|
|
Dominoes posted:I'm with you. For ref, my background is Python (which has an option static type checker) Python has a super() keyword; I've no idea how to use it! The only time I've been using it in TS is for React boilerplate. I look at classes more as datatypes you can make. super in Python is not the same as super in JS. Really, super in python is mis-named. Python's super should be named something like next_in_line or something because of multiple inheritance and the MRO's linearization.
|
|
#
?
Apr 20, 2017 22:20
|
|
|
Honest Thief posted:The more I get into ES6 and typescript the more I get iffy about using the super() keyword in Javascript. I came from a Java and C# background and part of the reason why I wanted a change of pace was because I was getting tired of class inheritance programming, also because I kinda hated programming in Eclipse, but whenever I see a recent-ish "how to do x in react" article there's always classes. I am a java dev, so I like the class structure and like everything self-contained. It stops me from writing massive blocks of JS blindly and helps me keep things organized like I would in Javaland. I haven't found a good reason for Inheritance with React (and their docs say the same thing). I did try out of curiosity and didn't run into any major issues.
|
|
#
?
Apr 21, 2017 02:25
|
|
|
Thermopyle posted:super in Python is not the same as super in JS. Really, super in python is mis-named. Python's super should be named something like next_in_line or something because of multiple inheritance and the MRO's linearization. 2 Qs: Just found out about Maps as an object alternative. Initial impression is they're more like a python dict, in that you can easily iterate through key/value pairs, and aren't intended to have methods etc. But they have ugly syntax. Is this about right? Why'd someone think giving it the same name with diff cap of a common operation is a good idea? Is there a way to make date-only and time-objects? Both the built in Date type, and moment, seem to use the datetime-only concept. I tried this with a Python module called Arrow a while ago, and eventually realised I hated it. (Can go into reasons if anyone's curious) Is there a way to make date-only and time-only objects? Then you could combine them with a func into a DateTime if you'd like, or get them using .Date() / .Time() methods from DateTimes etc. Would making a module like this from built-in or moment be feasible? I've been working mostly off ISO-serialized date and time strings until I need to calculate things to get around this. :/ Dominoes fucked around with this message at 00:45 on Apr 23, 2017 |
|
#
?
Apr 23, 2017 00:40
|
|
|
Dominoes posted:Initial impression is they're more like a python dict, in that you can easily iterate through key/value pairs, and aren't intended to have methods etc. But they have ugly syntax. Is this about right? Yes, this about sums it up I think. I just don't use them because the syntax is just icky when you're used to python dicts.
|
|
#
?
Apr 23, 2017 01:02
|
|
|
You can iterate objects easily now tooJavaScript code:
|
|
#
?
Apr 23, 2017 01:55
|
|
|
For people who find the accreted mess of native JS Maps, etc a bit much, I heartily recommend Immutable.js. Very efficient immutable collections, lazy evaluation options, and consistent methods and easy conversions across list/map/set/stack data structures.
|
|
#
?
Apr 28, 2017 03:44
|
|
|
|
| # ? Apr 25, 2024 20:50 |
|
|
Roadie posted:For people who find the accreted mess of native JS Maps, etc a bit much, I heartily recommend Immutable.js. Very efficient immutable collections, lazy evaluation options, and consistent methods and easy conversions across list/map/set/stack data structures. Immutable.js and Collections.js are both really good. But I've been leaning towards Immutable. It helps that they both mirror Collections in Java
|
|
#
?
Apr 28, 2017 05:08
|
|