|
Anyone have a recommendation for a graphql course or training resource for someone with a lot of frontend JS experience, not so much backend?
|
# ? Mar 20, 2020 12:01 |
|
|
# ? May 15, 2024 03:16 |
|
Just found this thread and was wondering how you'd deal with this issue. When I used to do java you can make overloaded methods that accept different params. With JS I wasn't sure how to best handle this. What's your thoughts?
|
# ? Mar 22, 2020 22:52 |
|
sterster posted:Just found this thread and was wondering how you'd deal with this issue. When I used to do java you can make overloaded methods that accept different params. With JS I wasn't sure how to best handle this. What's your thoughts? Or if you just want overloads that accept fewer or more params, in JS params are optional so you can just check if each one is undefined and do the appropriate branching in the function.
|
# ? Mar 22, 2020 22:57 |
|
roomforthetuna posted:There's no overloads in JS or TS, you can either do fooInt, fooString, fooSomeObject, or (not recommended) you can do a function foo that takes a dynamic type, run a switch on the type, and call the appropriate fooInt/fooString/fooSomeObject from the switch. Okay, the checking undefined is something we thought about. We ended up just naming them. makeRequestId(id) and makeRequestGuid(guid) that make a request to an underlying service that accepts both. It's not the worst but was curious if there was a more elegant way I could have done it. Thanks
|
# ? Mar 22, 2020 23:09 |
|
Another way to do it would be with a parameter-object but I guess in your case you couldn't prevent someone from calling your function with both a GUID and an ID.
|
# ? Mar 22, 2020 23:17 |
|
go play outside Skyler posted:Another way to do it would be with a parameter-object but I guess in your case you couldn't prevent someone from calling your function with both a GUID and an ID. If you use Typescript you can use code:
|
# ? Mar 22, 2020 23:25 |
|
Roadie posted:If you use Typescript you can use It'll be both the most performant and easiest to read and understand option.
|
# ? Mar 23, 2020 00:26 |
|
Hopefully the right place to ask this: I did some digging into an online cut optimizer out of curiosity, and I pulled this bit of code out of it. Is it JSON or something I haven't learned about Javascript yet? code:
|
# ? Mar 23, 2020 18:42 |
|
D34THROW posted:Hopefully the right place to ask this: It's plain old javascript with some jQuery in it. These code:
jQuery creates a function called $ in the global scope to make it easier to type. e: nowadays, people are using jQuery less and less, and you can pretty much replace this function with document.querySelectorAll("..."). However, do note that the jQuery $ function returns a jQuery object so you can chain calls. document.querySelectorAll does not. cutList is probably a self-calling anonymous function. Hard to say without the last few lines of it. Usually self-calling anonymous functions are used to not pollute the global scope with functions that don't need to be used elsewhere. The syntax is like this code:
go play outside Skyler fucked around with this message at 19:17 on Mar 23, 2020 |
# ? Mar 23, 2020 19:15 |
|
I didn't realize this rabbit hole went so deep I'm barely scratching the surface here, it took me an hour yesterday to figure out why Firefox was throwing an error on .valueOf(). code:
|
# ? Mar 23, 2020 19:32 |
|
D34THROW posted:I didn't realize this rabbit hole went so deep I'm barely scratching the surface here, it took me an hour yesterday to figure out why Firefox was throwing an error on .valueOf(). This is indeed an associative array, also called just an "object". In JavaScript, you can declare new, complex tree objects using a JSON-like notation (it's not exactly the same but close enough for what you care about right now). An object in JavaScript can have functions, other objects. It's an associative array of whatever you want. Not exactly sure about my terminology here, maybe someone can chime in. I've been doing JS for so long that I'm basically not thinking about these things anymore. e: something I make EVERYONE who works in my team read is java script: The Good Parts. The book is relatively short and you can get it as an e-book for a fistful of dollars. Definitely read it if you want to avoid common pitfalls and write good code. Nowadays it's a bit dated in the solutions it offers, what with the new EcmaScript standards, but the gist of it is still very good. go play outside Skyler fucked around with this message at 19:46 on Mar 23, 2020 |
# ? Mar 23, 2020 19:42 |
|
D34THROW posted:I didn't realize this rabbit hole went so deep I'm barely scratching the surface here, it took me an hour yesterday to figure out why Firefox was throwing an error on .valueOf(). JS objects can definitely have something analogous to methods - that is, instance members that are functions.
|
# ? Mar 23, 2020 23:15 |
|
I was thinking about taking an online React course because I kind of fell out of it after some early experiments, and I have a lot of free time now. I started just as Hooks were coming into favor. Are there any courses that are recommended? Udemy is having another of its sales. There are others like Wes Bos or Tyler McGinnis, but they're more expensive.
|
# ? Apr 9, 2020 05:14 |
|
LifeLynx posted:I was thinking about taking an online React course because I kind of fell out of it after some early experiments, and I have a lot of free time now. I started just as Hooks were coming into favor. Are there any courses that are recommended? Udemy is having another of its sales. There are others like Wes Bos or Tyler McGinnis, but they're more expensive. I just followed this video, with lots of pausing, typing, googling and additional reading. https://youtu.be/Ke90Tje7VS0 Then do Redux afterwards. Then throw it all away and do Elm.
|
# ? Apr 9, 2020 07:05 |
|
Learn redux and all about why you need to have immutable state and all that. Then try out vuex and realise that having mutable state that just triggers updates when you change it is so... so... so much darn easier.
|
# ? Apr 9, 2020 17:17 |
|
Nolgthorn posted:Learn redux and all about why you need to have immutable state and all that. Then try out vuex and realise that having mutable state that just triggers updates when you change it is so... so... so much darn easier. Until it isn't.
|
# ? Apr 11, 2020 20:52 |
|
Is Array.filter stable? Can I count on elements in the produced array to be in the same order as in the original array? MDN doesn't say anything about it. Limited tests suggest that it is, but I'd like a little more confidence than that...
|
# ? Apr 12, 2020 22:55 |
|
Newf posted:Is Array.filter stable? Can I count on elements in the produced array to be in the same order as in the original array? MDN doesn't say anything about it. Limited tests suggest that it is, but I'd like a little more confidence than that... Yes. Read through the ecmascript spec and it's pretty straightforward if a bit, umm...stilted...in it's wording. http://ecma-international.org/ecma-262/5.1/#sec-15.4.4.20
|
# ? Apr 12, 2020 23:11 |
|
Lumpy posted:Until it isn't. Turns out they're deprecating that, their documentation already says you can't even though you still can. Oh well. It seems plain to me that sometimes you need a mutation and sometimes you don't.
|
# ? Apr 13, 2020 02:05 |
|
Thermopyle posted:Yes. That's just how spec-ese reads. Honestly, I like it, it tends to be pretty explicit.
|
# ? Apr 14, 2020 04:01 |
|
I have been brought in to save the bacon for a startup that has been around for a couple years and has no (ok like 5%) test coverage for their high-risk product. It's important enough that people could indirectly die (or be maimed) if the product fucks up, but its not controlling any important real-time applications. So I can be a little fast and loose in order to get things tested, but I reaaaallllyyyyy should be adding tests before making any significant changes. I am struggling with adding tests to their code without complete rewrites of everything piece by piece. I am familiar with the usual methods of salvaging code like refactoring out hard dependencies using dependency injection, introducing common design patterns, and separating component responsibilities. However, I am facing a couple unique javascript challenges. I am trying to test a file that was written like this: My Module code:
code:
This seems like a problem unique to javascript because most other languages enforce the usage of Classes, so I would normally just extend the class with a Mock and call it a day. I was thinking that if I refactored this module to use Classes then I wouldn't have this issue at all, but it would require changing hundreds of references in the code. I was also thinking about trying to create export wrappers around the classes like so, but I have a feeling this won't work: code:
But in the short-term does anyone know a good solution around this issue that doesn't involve rewriting the entire module to make it testable? In this case, I could just test AorB directly or just do the DB stuff in the AorB test, but this situation is definitely going to keep popping up on me as I work through this so I want something in my toolbox to deal with it effectively. twig1919 fucked around with this message at 05:35 on Apr 14, 2020 |
# ? Apr 14, 2020 05:32 |
|
Redux is a lot easier to use now that it has hooks, but the huge boilerplate of creating actions/generators/reducers for everything makes it really cumbersome. Then you find yourself wondering why one dispatch fired off a million state changes (its because you wrote bad code). Then you just end up putting the user data into redux and then not bothering with anything else.
|
# ? Apr 14, 2020 06:05 |
|
twig1919 posted:I have been brought in to save the bacon for a startup that has been around for a couple years and has no (ok like 5%) test coverage for their high-risk product. My somewhat naive gut impulse (without knowing much else about what all you got going on) is to break A, B, and AorB into three separate files. AorB.js will import A.js and B.js from elsewhere. And since they're now imports, in your AorB test file you can jest.mock the imports for A or B and have separate unit tests for those two separately. I've used jest.mock a fair amount and I'm pretty sure it mocks internal function calls from imports just fine.
|
# ? Apr 14, 2020 07:49 |
|
IMO get rid of AorB and use if statements at caller sites. Call sites should be statically verifiable since they're module imports, if I'm remembering the rules for those correctly.
|
# ? Apr 14, 2020 13:14 |
|
Anony Mouse posted:I'm not familiar with sinon, I'm more familiar with jest class mocks. This was my instinct as well in fact I don't think you can test functions inside of a file, you're not really supposed to be doing that anyway. The only way I know of that you could would be to put them in a struct/object and then change the members of the struct/object from inside of the tests but that might be unnecessarily messy. At the very least I'd make AB.js which exports both, along with all the shared crap they probably both use, as the OP said they were clumped together. Then you could mock them pretty easily. I definitely wouldn't refactor into classes though OP, these are functions right? You're not going to make a javascript singleton right? Nolgthorn fucked around with this message at 13:38 on Apr 14, 2020 |
# ? Apr 14, 2020 13:35 |
|
Munkeymon posted:IMO get rid of AorB and use if statements at caller sites. Call sites should be statically verifiable since they're module imports, if I'm remembering the rules for those correctly. Yes this is the ultimate plan, the only issue is that the callers are at 0% test coverage. So I don't want to gently caress with them yet, but I want to set them up for refactoring after adding tests. Intelli-sense does not work for these because the way they are imported is something like as follows mainSQLStuff code:
So for some reason this causes intellisense to not calculate/recognize where any of the exports are used. Why they chose to do this is beyond my comprehension Anony Mouse posted:I'm not familiar with sinon, I'm more familiar with jest class mocks. This is a good idea. I will consider this to salvage something that's truly hosed. Nolgthorn posted:This was my instinct as well in fact I don't think you can test functions inside of a file, you're not really supposed to be doing that anyway. Nolgthorn posted:I definitely wouldn't refactor into classes though OP, these are functions right? You're not going to make a javascript singleton right? Here me out on the class thing because I don't intend to create a singleton. These files export functions, but whether they are actually *just* functions is questionable to me. This is how the file is setup: My Module code:
So this is mainly happening because they are doing stuff like the following (which is what I am trying to fix): code:
Other Module code:
Also, they have business logic all over their controllers (complexity 30+ all over the place) which require updating constantly. So to add 1 new (unrelated to existing functionality) property to a class, I'm looking at changing 15-20 files at the end of the day (to add the new property everywhere that table is mentioned). So, I was thinking these should all be replaced with Classes that do something like this My Model code:
Essentially this turns their SQL-ball into something more approximating a logical structure and the changes will be more localized to 1 place (the goal is to bring the change surface to 2-3 files for a new property: the model, vuex store, and front-end). I also plan to add some dependency injection for things like databases, configs, ect. because all that stuff is loading stuff from the environment on import which makes testing it difficult. The challenge I am having on that front is that importing things via dependency injection breaks VS-Code intelli-sense, which is annoying. twig1919 fucked around with this message at 15:44 on Apr 14, 2020 |
# ? Apr 14, 2020 15:15 |
|
What you're describing at least in part is the Active Record Pattern. That's a perfectly good use of classes in my opinion, it's not really my favourite approach anymore, I think you might be setting yourself up for a lot of work. Don't low-ball your time estimate! That changing the key case stuff is a pretty common mechanism, unfortunately it's repeated going one way and then back the other way often in many different places. I prefer having just a single case translator that's used for all tables, those two methods can be written in a few lines of code. But as it happens, the long form version gets screwed with over time and eventually it becomes impossible. I've tried writing Active Record Patterns and it was time consuming because ideally you have the ability to just change some properties and call ".save()" but that's more complicated than it seems.
|
# ? Apr 14, 2020 15:47 |
|
Nolgthorn posted:What you're describing at least in part is the Active Record Pattern. That's a perfectly good use of classes in my opinion, it's not really my favourite approach anymore, I think you might be setting yourself up for a lot of work. Don't low-ball your time estimate! Ah, I knew that there was a name for it but it wasn't coming to mind. Thanks for linking that! And yeah, I am definitely leaning towards Laravel's Eloquent, which is pretty much the best Active Record system I have used. In reality I am really just dealing with a pretty basic CRUD app (less than 100 tables) but then they need to add stuff like filters across and the whole things starts to explode into a mess when merging sql strings together. IMO, they wrote most of this with an smart but inexperienced developer who chose the wrong abstraction over and over until the thing turned into a mess. My main issue is that right now they are just trying to generate SQL which is turning into spaghetti in Javascript. I am all ears for whatever I can do to recover their API logic into something sensible, what approach do you favor over Active Record now? twig1919 fucked around with this message at 16:13 on Apr 14, 2020 |
# ? Apr 14, 2020 16:02 |
|
My main issue with active record, as is common with all software -- what you need it to do is never what you initially programmed it to do. When you start putting things into classes it all goes to hell. It's in my opinion probably the single biggest failure of object oriented programming as a whole. Because you think "yeah sure we'll just CRUD" but then you need a complex multi table query. Then you need sql transactions. Then you need to run sql on a different sever for one particular table. Then this then that. Instead of ramming my head against a wall I just prefer to explicitly write everything these days. I start at surface level and I type a function that describes what I want to do "user_has_updated_their_billing_address()" or similar. Then I write that function and so on. If there's a point where I'm duplicating something more than twice I abstract away that single part. Like my example of changing string case on keys in an object, that's easy enough to do so it's an imported function now. When I use classes it's always really really sparing, I consider them only data containers 99% of the time. I don't think code and data belongs in the same place. But this is just m opinion. OOP certainly has been popular enough over the years.
|
# ? Apr 14, 2020 16:22 |
|
Yes, this is typically my approach as well because the cost of the wrong abstraction is just so high: https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction. I am dealing with a situation where there are so many wrong abstractions that I am reaching for the hammer solution to at least have only 1 wrong abstraction, but maybe this is a fundamentally flawed approach. Thanks for the advice!
|
# ? Apr 14, 2020 16:37 |
|
Argh it's module hell again. I have a Typescript thing that is working in nodejs. I'm trying to also add a node-turn server to it. https://www.npmjs.com/package/node-turn I've done yarn add node-turn which has done its thing. There is no @types/node-turn. node-turn's main file is of the form code:
code:
code:
maybe relevant bits under compilerOptions code:
code:
code:
|
# ? Apr 16, 2020 04:58 |
|
Got a code repo you can point us at?
|
# ? Apr 16, 2020 07:45 |
There's always the option of just using the node-turn part as regular JS? Create your own wrapper interface with some any type overrides if you want to isolate that part from your typed code. I may be missing something though, I'm only getting started with this stuff myself.
|
|
# ? Apr 16, 2020 11:46 |
|
Osmosisch posted:There's always the option of just using the node-turn part as regular JS? Create your own wrapper interface with some any type overrides if you want to isolate that part from your typed code. I might just go with running the TURN stuff as a completely separate executable, that way I don't have to get my package configuration to pair up with a seemingly incompatible package configuration. Ah! I found my problem, it was something completely different - "yarn start" wasn't performing a rebuild unless it succeeded, after which it would do a hot reload. So I had a mistake in one of the versions then every attempt to try something different didn't actually even try, and just returned the same error. Sorry for the waste of time question! (The fix being to "yarn build" before "yarn start" again.) Edit: for completeness' sake, the answer was yes I did need "esModuleInterop": true in tsconfig, the correct import line was import Turn from 'node-turn';, and the type declaration file that worked was code:
roomforthetuna fucked around with this message at 00:05 on Apr 17, 2020 |
# ? Apr 16, 2020 23:57 |
|
Try using import lib = require('package');. This is a special form in typescript for CJS packages. https://www.typescriptlang.org/docs/handbook/modules.html#export--and-import--require E: whoops, missed your edit
|
# ? Apr 17, 2020 14:15 |
|
A few years ago, after a drunken conversation at DragonCon, I ended up writing a little script to output every possible syllable of the Klingon language. The surrounding HTML uses the <pre> tag so I could use document.writeln(). The idea here is that every logical combination of onset, nucleus, and coda is legit, except ones that contain the substrings "ow" or "uw". (The empty string at the beginning of the codas array is make creating the syllables that are just consonant-vowel easier.)code:
Kraus fucked around with this message at 17:55 on May 5, 2020 |
# ? May 5, 2020 17:40 |
|
code:
n=="o"||"u" evaluates as (n=="o")||"u" because of the operator precedence, so it's checking the nuclei against 'o' then, if that's false, evaluating whether a string composed of the character u is truth-y, which it is. Your friend was right in that it doesn't matter what comparison you do, the expression inside those parenthesis always evaluates to true. e: I suspect what you meant was (n == 'o' || n == 'u') Munkeymon fucked around with this message at 18:01 on May 5, 2020 |
# ? May 5, 2020 17:56 |
|
Munkeymon posted:
It's also a good opportunity to try out map/filter stuff. JavaScript code:
|
# ? May 5, 2020 19:11 |
|
Thanks for all the replies, y'all! As a side note, that friend and I managed to get the one liner inside the loops down to this: n>"n"&c[0]=="w"||document.writeln(o+n+c) This abuses both operator precedence and the fact that the Unicode values of "o" and "u" are greater than the Unicode value for "n". Edit: It also abuses the fact that the > and the == get evaluated to boolean values, which the bitwise AND can deal with. Kraus fucked around with this message at 21:58 on May 5, 2020 |
# ? May 5, 2020 21:50 |
|
|
# ? May 15, 2024 03:16 |
|
I am moving my Contentful API calls from my React app to my Express API, merely wrapping my Contentful calls in routes:code:
EDIT: Seems like any response over 60kb is having this issue vs limit size. Boosh! fucked around with this message at 14:54 on May 7, 2020 |
# ? May 7, 2020 14:38 |