|
Dumb Lowtax posted:I feel like if you've got a good background on pointers and references from a C++ background or a quality CS intro class you just don't ever have that misunderstanding
|
# ? Feb 3, 2019 01:36 |
|
|
# ? Jun 3, 2024 22:49 |
|
Deep clone is an example of people using too many libraries for simple operations, in my opinion. All it takes is something like this and you get to tweak it to do whatever it is you need it to do.JavaScript code:
|
# ? Feb 3, 2019 04:38 |
|
Nolgthorn posted:Deep clone is an example of people using too many libraries for simple operations, in my opinion. All it takes is something like this and you get to tweak it to do whatever it is you need it to do. I mean at this point you may as well just use Object.assign since your function doesn't protect against the standard pitfalls of cloning objects.
|
# ? Feb 3, 2019 07:41 |
|
What pitfalls
|
# ? Feb 3, 2019 07:47 |
|
Nolgthorn posted:What pitfalls
|
# ? Feb 3, 2019 07:52 |
|
Alright yeah a circular reference is not handled by my function, what do you use circular references for if you don't mind me asking? JSON.stringify also doesn't handle circular references. But you can handle them with my function using a second parameter.
Nolgthorn fucked around with this message at 08:21 on Feb 3, 2019 |
# ? Feb 3, 2019 08:18 |
|
code:
code:
|
# ? Feb 3, 2019 08:44 |
|
Nolgthorn posted:
so why are you doing this rather than json.stringify/json parse again?
|
# ? Feb 3, 2019 09:13 |
|
Again JSON stringify throws an error on circular references. If you generate a circular reference in your code, correct behaviour is that your application shits itself as soon as possible so that you can figure out where you did that and fix it. But someone might need that or any number of different things. The point is to write code that says what you are doing, so that when someone comes along later they don't have to guess what the point of your code is. Probably what you are doing is more than just deep cloning the object, otherwise why would you be doing it. So while you're traversing it, perform your mutations in place. You're making a new object to serve some purpose, It's explicit.
|
# ? Feb 3, 2019 09:22 |
|
Nolgthorn posted:What pitfalls You code does quite surprising things when it clones anything which inherits from Object but is not a plain old Object, such as a function, date, regular expression object, boxed String or typed array. Essentially it ignores the prototype chain. It also doesn't preserve additional string properties of arrays, or symbol properties of objects. Object properties which are read-only, accessor (getter-setter), non-configurable or non-enumerable also do not have these attributes preserved. Most of these issues can be fixed, but cloning functions is the really insurmountable issue here. Functions are essentially uncloneable because of the old "do this!" problem: JavaScript code:
(This is kind of like touching your nose and saying to someone, "Do this!" Should they touch your nose, or touch their own nose?) And having noted that cloning a function is something which is to be avoided, we then realise that essentially every JavaScript object has methods on it... Anyway... it's true that JSON.parse(JSON.stringify(...)) also has problems with this kind of input (and it mishandles other, dumber things too, like undefined, Infinity, -Infinity and NaN). The point is that JSON.parse(JSON.stringify(...)) is a universally known quantity, including all of its warts, whereas for any given third-party cloning library it's anybody's guess which of these edge cases are handled well and which are not.
|
# ? Feb 3, 2019 15:25 |
|
Just use lodash.cloneDeep. It handles circular references and almost certainly does so better than anything you can come up with in a reasonable amount of time.
|
# ? Feb 3, 2019 21:32 |
|
Hmm, you seem to be putting a lot of effort into this cloning code to fix up all the edge cases you run into. Maybe you should make it a library so that you only need to do it once instead of repeating it on every single project?
|
# ? Feb 4, 2019 04:50 |
|
there is a reason why no one wants to gently caress with cloning and if they do they pray a shallow clone of their object will suffice.
|
# ? Feb 4, 2019 07:19 |
|
I maintain that you should know what's in your objects and why you are cloning them and write code that does what you want it to do.
|
# ? Feb 5, 2019 12:46 |
|
Nolgthorn posted:I maintain that you should know what's in your objects and why you are cloning them and write code that does what you want it to do. I maintain that you should have a vague idea what's in your objects and why you are cloning them and hope the code you copied and pasted from SO does what you want it to do.
|
# ? Feb 5, 2019 14:14 |
Jabor posted:Hmm, you seem to be putting a lot of effort into this cloning code to fix up all the edge cases you run into. Maybe you should make it a library so that you only need to do it once instead of repeating it on every single project? This discussion has been such a beautiful slow burn.
|
|
# ? Feb 5, 2019 14:28 |
|
All this clone talk is one of the reasons that no-mutation patterns like Redux are so popular.
|
# ? Feb 6, 2019 03:02 |
|
Roadie posted:All this clone talk is one of the reasons that no-mutation patterns like Redux are so popular. But how do you clone your objects in your reducers to return non-mutated versions?
|
# ? Feb 6, 2019 04:15 |
|
Lumpy posted:But how do you clone your objects in your reducers to return non-mutated versions? You don't. You use object spread, which uses the same references for non-changed values.
|
# ? Feb 6, 2019 04:25 |
|
allocation is sin, do not generate more GC garbage after page load.
|
# ? Feb 6, 2019 04:27 |
|
Suspicious Dish posted:allocation is sin, do not generate more GC garbage after page load. But if I can't post here how am I supposed to waste time at work?!
|
# ? Feb 6, 2019 14:53 |
|
Roadie posted:You don't. You use object spread, which uses the same references for non-changed values.
|
# ? Feb 6, 2019 20:23 |
|
We have an internal dependency that takes a mandatory id parameter for one function. Currently, if you forget the parameter, it will error out randomly deep in the code when it calls toString on an undefined id. What’s a typical way to handle this in JavaScript? Throw an error or console warn (or throw and warn)? smackfu fucked around with this message at 01:13 on Feb 7, 2019 |
# ? Feb 7, 2019 01:09 |
|
smackfu posted:We have an internal dependency that takes a mandatory id parameter for one function. Currently, if you forget the parameter, it will error out randomly deep in the code when it calls toString on an undefined id. Switch to Typescript so that it's impossible to forget the mandatory params.
|
# ? Feb 7, 2019 09:17 |
|
Roadie posted:Switch to Typescript so that it's impossible to forget the mandatory params. Use Flow so you don't have to rewrite your codebase in Typescript.
|
# ? Feb 7, 2019 10:44 |
|
smackfu posted:We have an internal dependency that takes a mandatory id parameter for one function. Currently, if you forget the parameter, it will error out randomly deep in the code when it calls toString on an undefined id. In any language, even those saner than JavaScript, if a parameter to a function must not have certain values, the function should fail as fast as possible and as loudly as possible. Throw exceptions, write to the console, start the fire alarm, anything you can think off. The second that function is called with incorrect values the caller must know in no uncertain terms that it is not acceptable.
|
# ? Feb 7, 2019 13:22 |
Input validation is duck typing 101. The same if you're dealing with indirection in any language. If your compiler doesn't check your types, you have to as soon as a scope receives it.
|
|
# ? Feb 7, 2019 13:40 |
|
huhu posted:Use Flow so you don't have to rewrite your codebase in Typescript. Isn't Flow practically dead by JS standards? (no updates in over 6 months or something) I found typescript more intuitive and better supported than flow but I'm also a Java / Kotlin dev and am full tilt IntelliJ which has excellent support for TS.
|
# ? Feb 8, 2019 00:40 |
|
Does anyone else think it's nuts that both builtin Date, and moment.js (Which I believe represent the large maj of date handling) don't have separate date and time types? AFAIK, the convention is to use their datetime times for dates, times, and datetimes, which is a recipe for subtle bugs. I've been using ISO strings or tuples, processing them using one of these libs are needed, then converting back.
|
# ? Feb 8, 2019 01:54 |
|
geeves posted:Isn't Flow practically dead by JS standards? (no updates in over 6 months or something) Yeah, afaics it looks that way. It's not completely dead, but the lack of updates & watching bigger projects migrating away (Yarn for example) does look like nails being hammered into the coffin. It's kinda looks like FB have just lost interest, & without that backing it I don't see how it can compete I was the other way round in terms of intuitiveness - I like the OCaml type system a lot better than TS' system. It has some nice advantages, primarily that it works with plain JS with the annotations in comments. That's a bit onerous, but if not in comments the annotations can really easily be stripped out by Babel. I do wonder how much of the failure is to do with it not playing well with VSCode, having to disable the JS language features just to use Flow is nuts RobertKerans fucked around with this message at 02:20 on Feb 8, 2019 |
# ? Feb 8, 2019 02:18 |
|
Dominoes posted:Does anyone else think it's nuts that both builtin Date, and moment.js (Which I believe represent the large maj of date handling) don't have separate date and time types? AFAIK, the convention is to use their datetime times for dates, times, and datetimes, which is a recipe for subtle bugs. I've been using ISO strings or tuples, processing them using one of these libs are needed, then converting back. If you're just saving dates and times as a string without time zones (not offsets, zoneinfo time zones like "America/Los_Angeles"), you're doing it wrong and it's going to eventually cause problems when you run into dates or times that don't actually exist (there's a bunch of them), bizarro offsets, Daylight Savings making the clock rewind, etc. The reason these libraries are all datetimes is because what they're actually storing is a POSIX timestamp in absolute milliseconds, and everything else is just convenience methods to input/output/adjust that value. This way the systems just tick from 915148800 to 915148801 even though the wall clock time just rewound an hour because of DST changes or wall clock time just jumped forward 30 minutes because legislators decided to move to a half-hour time zone (it's a real thing).
|
# ? Feb 8, 2019 03:20 |
|
Flow looks pretty active on Github. Not sure what you guys are talking about.RobertKerans posted:I do wonder how much of the failure is to do with it not playing well with VSCode, having to disable the JS language features just to use Flow is nuts
|
# ? Feb 8, 2019 03:31 |
|
Roadie posted:If you're just saving dates and times as a string without time zones (not offsets, zoneinfo time zones like "America/Los_Angeles"), you're doing it wrong and it's going to eventually cause problems when you run into dates or times that don't actually exist (there's a bunch of them), bizarro offsets, Daylight Savings making the clock rewind, etc. Dominoes fucked around with this message at 03:53 on Feb 8, 2019 |
# ? Feb 8, 2019 03:38 |
|
Okay, but what happens when your user travels from Samoa to New Zealand?
|
# ? Feb 8, 2019 03:50 |
|
Jabor posted:Okay, but what happens when your user travels from Samoa to New Zealand? For example, if you're storing airplane land times, you must use a datetime. If you're setting up a series of daily schedules, standalone dates (and in some cases, times) make more sense. Dominoes fucked around with this message at 03:55 on Feb 8, 2019 |
# ? Feb 8, 2019 03:52 |
|
TS has more momentum now but even if everyone stops using flow that doesn't necessarily mean that Facebook will stop developing it.
|
# ? Feb 8, 2019 03:55 |
|
It's relevant more often than you'd think, and you might as well always store a datetime with a timezone so that you're already prepared if it turns out you do need it.
|
# ? Feb 8, 2019 03:57 |
|
The worst is when someone converts an ISO date into a date time of midnight UTC on that date (for instance by passing it to parse), then the local time zone is negative (like US ones) so the displayed date ends up one day earlier than you started with.
|
# ? Feb 8, 2019 04:28 |
|
Dominoes posted:If you're setting up a series of daily schedules, standalone dates (and in some cases, times) make more sense. It only makes more sense as long as everyone who uses it never travels between time zones and never coordinates with anyone who lives in a different time zone. Consider, for example, that "I'm open from 9 AM to 9 PM Saturday for a video conference" from somebody in London actually means "from 9 PM Saturday to 9 AM Sunday" in New Zealand.
|
# ? Feb 8, 2019 05:56 |
|
|
# ? Jun 3, 2024 22:49 |
|
A good date-time library allows you to choose whether you want a local date, a local time, or an absolute date time, since there are use cases for all of them.
|
# ? Feb 8, 2019 14:04 |