|
Any thoughts on loading common external libraries like Lodash from unpkg or cdnjs instead of adding them to my bundle via npm/yarn? Faster load time (assuming user has package cached already), but I'm thinking there are downsides as well.
|
#
?
Mar 4, 2018 20:28
|
|
|
|
| # ? Jun 10, 2024 10:12 |
|
|
I like the idea that you should get more performance, but I also don't exactly like the security implications of serving stuff from a third party. (I usually just serve it from the cdn)
|
|
#
?
Mar 4, 2018 20:46
|
|
|
Is there a big security risk associated with enabling cross origin resource sharing on a website? I added flask-cors so that my Flask backend can serve CSV files to my React frontend and I'm not sure what kind of Pandora's box I'm opening.
|
|
#
?
Mar 5, 2018 00:47
|
|
|
Analytic Engine posted:Is there a big security risk associated with enabling cross origin resource sharing on a website? I added flask-cors so that my Flask backend can serve CSV files to my React frontend and I'm not sure what kind of Pandora's box I'm opening. Yes, it's the same risk as CSRF but for any requests you allow, from any domains you allow.
|
|
#
?
Mar 5, 2018 03:03
|
|
|
Analytic Engine posted:Is there a big security risk associated with enabling cross origin resource sharing on a website? I added flask-cors so that my Flask backend can serve CSV files to my React frontend and I'm not sure what kind of Pandora's box I'm opening. If you are careful about only opening it to a domain you control then the risks are only as high as the risk that someone might inject JavaScript into your site. If you've taken the appropriate steps to secure against that, then the act of allowing CORS for that domain name is not especially risky. Of course any additional attack vector you add to a system necessarily increases your risk, but we're talking about a pretty acceptable level of risk here I think.
|
|
#
?
Mar 5, 2018 06:13
|
|
|
Sedro posted:Yes, it's the same risk as CSRF but for any requests you allow, from any domains you allow. a hot gujju bhabhi posted:If you are careful about only opening it to a domain you control then the risks are only as high as the risk that someone might inject JavaScript into your site. If you've taken the appropriate steps to secure against that, then the act of allowing CORS for that domain name is not especially risky. Of course any additional attack vector you add to a system necessarily increases your risk, but we're talking about a pretty acceptable level of risk here I think. Thanks Maybe I'm missing something, but it seems like you can't make a publicly accessible RESTful API without enabling CORS on the responses. We want to serve JSON blobs to people's requests no matter where they come from. If this isn't a CORS issue then what's a good book or blog to understand it better?
|
|
#
?
Mar 5, 2018 06:35
|
|
|
Analytic Engine posted:Thanks You can, just so long as the JavaScript that uses the API is hosted on the same domain as the API itself. The "Origin" in CORS that we're talking about here is the page hosting the JavaScript, not the user's machine executing the JavaScript.
|
|
#
?
Mar 5, 2018 06:39
|
|
|
a hot gujju bhabhi posted:You can, just so long as the JavaScript that uses the API is hosted on the same domain as the API itself. The "Origin" in CORS that we're talking about here is the page hosting the JavaScript, not the user's machine executing the JavaScript. Well, we want it to be a public API so for the most none of the JS that uses the API will be on the same domain. We have a frontend with test examples, but even that will probably have a different domain than the server hosting the API. Edit: So it sounds like someone could download setupAPIembed.js from our site, where all calls to the API originate from functions in that file, and it wouldn't require CORS. I guess I don't get how Instagram/Twitter/etc run API endpoints that can be queried from some random dude's XHR request and return a JSON object, without turning on CORS. Ultimately twiiter.com is serving a data file and anyone can download it. Analytic Engine fucked around with this message at 08:33 on Mar 5, 2018 |
|
#
?
Mar 5, 2018 08:27
|
|
|
Analytic Engine posted:Well, we want it to be a public API so for the most none of the JS that uses the API will be on the same domain. We have a frontend with test examples, but even that will probably have a different domain than the server hosting the API. Either they set Allow-Origin: *, or they expect their APIs to be called server-to-server and not directly from the browser, e.g. as fartbutt.com/awesometwitter.js -> api.fartbutt.com -> api.twitter.com. From what my googling tells me, Twitter's API does in fact not have CORS. There's no general requirement that an open API necessarily be accessible directly from the browser, and disallowing it may help mitigate both security issues and other abuse. For instance, it's a lot easier to block a single rogue backend API from hammering the public API than to block individual client IPs, although of course a dedicated attacker can get around such measures. But as long as you understand and correctly handle the risks (CSRF, for instance), there's nothing wrong with allowing all origins.
|
|
#
?
Mar 5, 2018 10:03
|
|
|
I'm starting to dabble in front end web dev to keep myself up to date, and I was looking through React and saw they had some recommended starter kits: https://reactjs.org/community/starter-kits.html I played around with Next.js and two hours later I had a deployed server side rendering SPA which is pretty dope. I'm a big proponent of not using a lot of "precanned" solutions, but this one seemed nice?
|
|
#
?
Mar 5, 2018 16:16
|
|
|
Doh004 posted:I'm starting to dabble in front end web dev to keep myself up to date, and I was looking through React and saw they had some recommended starter kits: https://reactjs.org/community/starter-kits.html It's good for getting MVPs up, but of course you'd want to have your entire build system understood by someone on your team if you are hinging your company's success on it not breaking in a year and no one knowing how to fix it.
|
|
#
?
Mar 5, 2018 16:45
|
|
|
god writing tests is so boring
|
|
#
?
Mar 5, 2018 20:56
|
|
|
90% of all programming is boring as gently caress
|
|
#
?
Mar 5, 2018 21:23
|
|
|
Ferdinand the Bull posted:It's good for getting MVPs up, but of course you'd want to have your entire build system understood by someone on your team if you are hinging your company's success on it not breaking in a year and no one knowing how to fix it. MVP might be pretty good. I'm thinking this could be good for a standalone microsite for us to test out some new concepts (to help break out of our monolith).
|
|
#
?
Mar 5, 2018 23:28
|
|
|
Grump posted:god writing tests is so boring I enjoy it. I have this nagging worry in the back of my mind that slowly goes away the more tests I write.
|
|
#
?
Mar 6, 2018 00:57
|
|
|
I really want to start forcing myself to stub out tests before I write something. A guy I work with spends a decent amount of time thinking about what the code he's writing is actually supposed to do, and then writes out empty or very generic tests and then builds out the actual code. I, on the other hand, just smash the keyboard until something works, and then spend too much time refactoring it so it actually makes sense to someone else.
|
|
#
?
Mar 6, 2018 02:48
|
|
|
ddiddles posted:I really want to start forcing myself to stub out tests before I write something. A guy I work with spends a decent amount of time thinking about what the code he's writing is actually supposed to do, and then writes out empty or very generic tests and then builds out the actual code. Up until 2 weeks ago i smashed the keyboard too. TDD is super useful, but right now i’m going through old code and writing tests for our legacy apps - it sucks. But it is really satisfying seeing the coverage badge on Gitlab go up!
|
|
#
?
Mar 6, 2018 04:11
|
|
|
I hardly ever write tests and I feel bad and like a fraud. TDD is legitimately faster in some scenarios but most of the time writing tests feels like the chore I have to do before I can move on and get more actual work done. I also find that unit tests are often next to useless at actually catching bugs and integration/e2e tests are just so slow to set up and maintain. But I would like that nagging feeling in the back of my head to go away so maybe I need to get better at it.
|
|
#
?
Mar 6, 2018 05:13
|
|
|
I find integration tests to be super useful. Being confident that everything still works without having to manually test things is great. Our legacy product without integration test has way more bugs make it to production on edge cases. OTOH, unit tests seem mostly useful during initial coding. You can test whether this little chunk of logic works properly in all cases without having to spin everything up. It’s not going to break spontaneously unless you actually change some of that code. We try to write tests for everything. It’s almost certainly overkill, and legitimately gets in the way of refactoring. But I think people would slack off really fast if we switched to writing only tests that are “needed.”
|
|
#
?
Mar 6, 2018 13:42
|
|
|
Every time I write a test, then later refactor the code that that test tested, so now I have to refactor the test, in addition to the code, I die. I just die.
|
|
#
?
Mar 6, 2018 13:47
|
|
|
I’ll admit I have no idea what the difference is among unit, e2e, integration, etc tests? Where do I learn this? I’ve mainly just been trying to test as many lines of code as possible and hoping for the best
|
|
#
?
Mar 6, 2018 14:54
|
|
|
Grump posted:I’ll admit I have no idea what the difference is among unit, e2e, integration, etc tests? Where do I learn this? I mean it's basically just: unit - testing small bits of your own code: does this function return the right thing when given this input? etc. e2e - a test for an entire process in your own code....well...end to end. Does this page call this thing correctly, then route to a new place when it gets back what it needed? etc. integration - testing how your code reacts when presented with input from another application entirely. Does my app do the right thing when it gets this info from a Common Auth system? etc AFAIK there's not much more to it than that.
|
|
#
?
Mar 6, 2018 15:59
|
|
|
Grump posted:I’ll admit I have no idea what the difference is among unit, e2e, integration, etc tests? Where do I learn this? TLDR: Unit tests test small pieces of code, integration tests test combinations of different pieces of code, e2e tests test the actual functionality of the software. A lot of people have strong opinions about how to do testing and what the different test types means. This is just my take. Unit tests test individual units of code, which typically means that you're testing a single function -- or sometimes a combination of a few different functions -- for some particular input. External dependencies such as databases, web services and the file system should be replaced with mocks or stubs, so the tests don't depend on anything else than the code. Some people feel that all external dependencies of the code under test should be mocked out, so if you're testing a method on class A, and the method calls a method on class B internally, then you should be using a mocked version of B where you decide exactly what the return value is, even if B is also part of your codebase. That way a bug in B will only cause test failures in tests for B, not tests for A. Other people are okay with "internal" dependencies in unit tests, as long as nothing external to the application is invoked. However, I believe even the most purist unit testers will accept the use of standard library functions/types, and possibly trusted third party code as well, in code covered by unit tests. Integration tests test the integration points between systems. In the context of webdev that typically means running tests that include API calls over a real HTTP connection, but against a fake server that returns predictable results for different inputs. It may also include making assertions about what the resulting HTML should look like when different events happen in the app. Integration tests should represent an "almost real" environment for the functionality that's being tested, but in a way that's predictable and reproducible. E2E (end to end) tests should test actual functionality on the basis of how users are expected to use the application. They may require human interaction, or they may be fully automated and use techniques like recording real user sessions in such a way that they can be played back programatically later. Some people even test that the pixels on the screen are what they're supposed to be (or sufficiently close to it) by comparing screenshots to reference images. I don't have much experience with any of this, so I can't tell you too much about best practices. Whereas unit tests are always written in the same language as the code under test, and preferably by the same person who wrote the production code, integration tests and end-to-end tests can often be written in a different language, by a different person or team, and may be (but don't have to be) maintained completely separately. Another important point is that unit tests should be small and fast, because you should have a lot of them, and you should run them every time you do a build. Integration tests are allowed to be slower, and you don't need to run them as often. All the types of tests have strengths and weaknesses. Integration tests are more likely to give false positives because the tests may fail due to factors beyond the tests' control, such as a network connectivity problem, or simply because they cover a lot of ground. Unit tests are more likely to give false negatives, because they often encode the same bugs and invalid assumptions that exist in the production code. Unit tests may also be more resistant to change. For instance with the A->B example above, if you've been mocking B but then change A so it doesn't depend on B anymore, your tests for A still stop working even though the externally visible behavior of A may be correct and unchanged. An advantage of unit tests is that they can be very precise and detailed, and they're great for testing obscure corner cases in algorithms. My experience with unit testing is that it's most useful for finicky code with few dependencies. A typical example of where unit tests are ideal would be a parsing routine, which takes a string as input and returns some data structure as output. You can easily write lots of unit tests for many different inputs and test that the output is as expected in each case. Unit testing things that depend on IO with external dependencies replaced by mocks can still be useful, but those are harder to write and typically more brittle, i.e. more likely to break even though nothing is wrong. There are other types of tests in addition to what I've mentioned here (e.g. regression testing, system testing), but this is getting long enough.
|
|
#
?
Mar 6, 2018 16:00
|
|
|
Web Development just seems needlessly frustrating. Was trying to add Bootstrap to my create-react-app project so that it looks prettier as a portfolio thing, and the TypeScript won't compile because the bootstrap dependency itself is hosed. This web development stuff seems simple enough to understand and do, but it's like you have to hand-make everything from scratch because even the most basic, fundamental stuff will break constantly and there's nothing you can do about it unless you want to build everything from the ground up by hand. Followed all of the directions in the create-react-app Github thing, too. If I remove @types/react-bootstrap from the package.json and prune the repo, then it still won't compile because it says that it's missing the package! 
|
|
#
?
Mar 7, 2018 07:38
|
|
|
If you find a programming discipline that's easy and that people are hiring for please let me know. In the meantime you can probably delete the @types package and just put "declare module 'react-bootstrap'" into src/index.d.ts and it should work. You won't get typings for the bootstrap components but it'll let you move on at least.
|
|
#
?
Mar 7, 2018 16:47
|
|
|
I spent 5 days sort of farting around the office doing bits and bobs and largely drinking coffee and roaming around because I was waiting for other people to finish poo poo then they all finished their poo poo at once and all of a sudden I had an absolute tonne of poo poo to do today which sucked. That's my story!!!
|
|
#
?
Mar 7, 2018 20:05
|
|
|
Today I learned that Angular 1.5 will deep-copy the list you use to make a select so if you try to do something clever whereHTML code:Cool. Great.
|
|
#
?
Mar 7, 2018 22:33
|
|
|
Does VueJS have a concept of a "service"? I'm trying to figure out how to initialize a singleton class to wrap an API and manage auth credentials and use it across multiple components and pages. If I just use a regular "import...from..." when I want to use the class of course it won't preserve state and I'll have to initialize it every time. I'm also incorporating Vuex and it's not yet obvious how best to expose the API class to a store module so I can make async requests in an action. Any tips?
|
|
#
?
Mar 8, 2018 02:25
|
|
|
I came across this syntax for stateless components in React:code:
|
|
#
?
Mar 8, 2018 03:05
|
|
|
You can if you convert to curly braces and explicitly return stuffcode:
|
|
#
?
Mar 8, 2018 03:38
|
|
|
porksmash posted:You can if you convert to curly braces and explicitly return stuff To add onto this: am reading a React Design Patterns book atm and there is an improvement that the book claims to be a best practice because of JSX readability or whatever. It goes like this: JavaScript code:
|
|
#
?
Mar 8, 2018 04:22
|
|
|
porksmash posted:You can if you convert to curly braces and explicitly return stuff Love Stole the Day posted:To add onto this: am reading a React Design Patterns book atm and there is an improvement that the book claims to be a best practice because of JSX readability or whatever. It goes like this: This is what I ended up doing, minus the ternary. Can ternary work well with multi-line returns? code:
|
|
#
?
Mar 8, 2018 05:00
|
|
|
my bony fealty posted:This is what I ended up doing, minus the ternary. Can ternary work well with multi-line returns? Yeah that's what I meant by the general purpose thing. Here's an example from a portfolio project I'm working on: https://github.com/wanderrful/korean-learning-app/blob/dev/src/components/Quiz.tsx#L98 What you do is put the multi line stuff into its own function and then call it so that it all fits in there and looks pretty.
|
|
#
?
Mar 8, 2018 05:28
|
|
|
Love Stole the Day posted:Yeah that's what I meant by the general purpose thing. Woah, an emoji right there in the HTML. How do you guarantee that the user can see the emoji, do you use a particular font that has symbols for emojis?
|
|
#
?
Mar 8, 2018 06:11
|
|
|
my bony fealty posted:I have also gotten in the habit of leaving parentheses off of arrow functions with one parameter in general and am not sure how I feel about it. I do like the flexibility ES6 gives but it is a lot to get used to. Install prettier and don't think about it!
|
|
#
?
Mar 8, 2018 06:20
|
|
|
my bony fealty posted:
Overall though I'm a pretty big fan of ternaries in JSX. I write a lot of stuff that looks like this: code:Anony Mouse fucked around with this message at 07:15 on Mar 8, 2018 |
|
#
?
Mar 8, 2018 07:12
|
|
|
Anony Mouse posted:Your example won't work because you can only return a single node from renders (and from ternary expressions). You'd need to wrap those header tags in a <div> or something. Ternary operators with long expressions are much more readable like this, so I think you're fine. It's what I do too. code:
|
|
#
?
Mar 8, 2018 07:26
|
|
|
Sedro posted:npm is unreliable by design if you don't use a lockfile and npm shrinkwrap was broken for as long as I used npm. yarn came along with working lockfiles and much better performance to boot. npm might be better now but there's no incentive for me to switch back. npm is also unreliable by design if you use a lockfile and you have developers with different versions of node and npm. I think everyone is finally back to normal with all the same versions madated, etc. But still. problems with npm have lead to about 20 instances of having to blow away repo because of package-lock.json
|
|
#
?
Mar 8, 2018 07:35
|
|
|
I dont think is a good idea to use ternary for long expressions / multiline. Ternary exist to have a more compact format where is still readable. To protect the surrounded code from some meaningless if that will only obscure why the code is doing what is doing. Anyway nothing is forbidden, everything is free, have fun and happy coding. Somebody somewhere has found CSS is turing complete and is compiling a bitcoin miner for it.
|
|
#
?
Mar 8, 2018 09:09
|
|
|
|
| # ? Jun 10, 2024 10:12 |
|
|
Anony Mouse posted:Your example won't work because you can only return a single node from renders (and from ternary expressions). You'd need to wrap those header tags in a <div> or something. (React 16.2 introduced <> as a shorthand notation, as well.) Tei posted:I dont think is a good idea to use ternary for long expressions / multiline. code:
|
|
#
?
Mar 8, 2018 12:04
|
|
