|
Does anyone have any experience getting a code-editor plugin working with React and TypeScript. I’ve tried like 4 different packages and they’re all a pain to integrate
|
#
?
Jul 9, 2018 22:06
|
|
|
|
| # ? Jun 7, 2024 17:56 |
|
|
Grump posted:Does anyone have any experience getting a code-editor plugin working with React and TypeScript. I’ve tried like 4 different packages and they’re all a pain to integrate What do you mean, like basic support for handling those frameworks with an editor? VS Code has all that stuff right out of the box, and you can always find some more extensions if you want some extra features. Edit: It sounds like you mean components for React that let you create a code-editing text field, like this http://securingsincity.github.io/react-ace/? In which case, never mind 
reversefungi fucked around with this message at 23:45 on Jul 9, 2018 |
|
#
?
Jul 9, 2018 23:42
|
|
|
Yeah i meant the latter. React ace looks awesome but is seemingly impossible to get setup with TypeScript
|
|
#
?
Jul 10, 2018 00:19
|
|
|
Well I just marked my ticket as DECLINED because it's clear after my third (fourth?) retry, I'm never going to get that Angular POC (more like POS) to work. Maybe I'll feel better being tasked other things an idiot baby like myself can actually deliver.
|
|
#
?
Jul 17, 2018 22:25
|
|
|
I have a child component with some form elements. On submit it would add an object to the parent state and clear the fields.code:It works now in its primitive state but I would eventually (I'm guessing) beef up addItem where if it fails, resetFields should not be run. I feel like I should move resetFields out of there and into maybe a lifecycle method and have addItem make the parent pass some prop down to trigger it.
|
|
#
?
Jul 25, 2018 16:10
|
|
|
There are actually many ways to handle that. But first and foremost, .setState(which I assume is in your addItems function) is asynchronous, meaning you can make the handleSubmit function an async function, set a return value inside of addItems and then await that return. Once you have the return, you can use a simple ternary to decide whether or not resetFields will run. Here's a really dumb version of how to explain this.code:
|
|
#
?
Jul 25, 2018 21:58
|
|
|
setState does not, however, return a promise. You have to feed it a callback function, which makes it really awkward to use as part of async code that uses promises and/or async/await. Facebook flat out refuses to change this because apparently doing something after setting the state is an anti-pattern (you are supposed to use the lifecycle methods instead). They still keep the callback parameter, though.
|
|
|
#
?
Jul 25, 2018 22:06
|
|
|
Great! That was very informative, thank you both.
|
|
#
?
Jul 26, 2018 00:04
|
|
|
Why do people like you like frameworks? Are you weak or are you stupid? Or both?
|
|
#
?
Jul 26, 2018 23:12
|
|
|
The Merkinman posted:Why do people like you like frameworks? Are you weak or are you stupid? Or both? Everything about that is terrible and illogical and i wish i hadn't read it. Thanks! Ok, well not everything. I do agree people should learn the basics. If you can't at least theoretically implement whatever framework you're using yourself, you're doing yourself a disservice.
|
|
#
?
Jul 26, 2018 23:20
|
|
|
But what are the basics though? Should everyone know how to implement a GET request using Assembly?
|
|
#
?
Jul 26, 2018 23:50
|
|
|
Tbh if you can't build a development environment from scratch, starting with mining and refining the raw materials from the pure depths of Earth, you shouldn't be using a computer for work at all
|
|
#
?
Jul 27, 2018 00:02
|
|
|
Small Brain: first frontend guy reinventing framework as they go in vanilla JS Large Brain: arguing over React vs Vue Galaxy Brain: forcing dozens of new hires to use first guy's spaghetti architecture
|
|
#
?
Jul 27, 2018 00:49
|
|
|
my bony fealty posted:Tbh if you can't build a development environment from scratch, starting with mining and refining the raw materials from the pure depths of Earth, you shouldn't be using a computer for work at all 
|
|
#
?
Jul 27, 2018 01:20
|
|
|
Ither posted:But what are the basics though? Whatever it is the framework is doing for you. For example, if you're using React, you should probably understand how to update the DOM yourself. Understand why the virtual DOM is useful. Understand on some theoretical level how you'd implement something roughly like it. If you're using a backend web framework, you should understand on a theoretical level how sockets work, how to respond to HTTP requests over them. Even if you couldn't sit down and implement them yourself right now, you should be able to see a clear path from where you are to your own implementation. I mean, it's not like you can't successfully use a framework if you can't do this, but you're going to be better if you can.
|
|
#
?
Jul 27, 2018 02:18
|
|
|
Thermopyle posted:Whatever it is the framework is doing for you. Nerd.
|
|
#
?
Jul 27, 2018 03:57
|
|
|
Analytic Engine posted:Galaxy Brain: forcing dozens of new hires to use first guy's spaghetti architecture This is me right now...
|
|
#
?
Jul 27, 2018 12:10
|
|
|
Lumpy posted:Nerd. Accurate. I was thinking about my post last night and I think it sounded more confident than I actually am. I think it might be true, and I feel like once I got to that point it made me better, but I don't know if the concept applies generally.
|
|
#
?
Jul 27, 2018 14:17
|
|
|
Thermopyle posted:Everything about that is terrible and illogical and i wish i hadn't read it. Thanks! Speaking as a former person who used frameworks and a JQuery, bootstrap and node.js contributor, I can see where this guy is coming from. a) In 2012, this attitude was totally correct. In 2012, people were still using JQuery even though JQuery is worse than useless, and were really into monolithic frameworks that were slow, hard to debug, and sucked total rear end. I still remember people sucking the v8 engines dick even though all the performance measurements made the assumption that no one used a try catch anywhere in the call stack, I remember google closure, Kendo UI, and angular 1, all of which were hilariously terribly implemented and evidence that no one ever reads the source code of this poo poo before trying to make web sites. People would talk about unit testing and then write all sorts of crazy poo poo - like I remember a mocking framework that went on for pages about its unit tests, and it was all pages of, literally, "ninja.swing()" that asserted nothing. There was an endless progression of grunt/bower/etc - people would start using all these tools, the developer would get bored of fixing problems, and then the devs would jump to a new project. b) 2017 has gotten a lot better - angular4 is actually a really smart web framework that has a lot of good features for writing maintainable SPA, including first class dependency injection support for components! .Net core is loving brilliant in that not only does it institutionalize first class dependency injection support, TestHost also always writing unit tests with a minimum of fuss. poo poo like babel and browserify actually work with a minimum of effort. Instead of SPA frameworks concentrating on solving the super difficult problem of "hey, you know, how do I update my view if my model changes, and vice versa", they provide useful features that you don't want to write yourself. Since JQuery is no longer a thing, you can actually loving use the "break on exceptions" feature in your browser's debugger without JQuery throwing exceptions in ordinary program flow whenever you move the mouse. That said, my point would be more "think for yourself, don't be sheep." loving put breakpoints in the libraries you are including, step through them, and figure out how they work, and analyze for yourself why they have value! Don't just use libraries because some dude at a meetup tells you they're the next best thing.
|
|
#
?
Jul 27, 2018 14:53
|
|
|
Bruegels Fuckbooks posted:good stuff Yeah, I agree. I mostly just had an issue with his click-bait title and the theres-no-shades-of-gray-here attitude.
|
|
#
?
Jul 27, 2018 19:15
|
|
|
as usual, arguing about programming metaphilosophy ends up going in circles with no new knowledge gained
|
|
#
?
Jul 27, 2018 19:56
|
|
|
He misses one of the most important features a framework or library provides: universality. Whole lot easier for me, someone who works with React, to jump into the React projects I inherited at work that were written by someone who also works with React, than it would be to try and untangle a dumpster of spaghetti, as was pointed out. ^^complaining about dumb JavaScript articles is its own reward
|
|
#
?
Jul 27, 2018 19:56
|
|
|
Suspicious Dish posted:as usual, arguing about programming metaphilosophy ends up going in circles with no new knowledge gained What is knowledge, though, man?
|
|
#
?
Jul 27, 2018 21:10
|
|
|
Analytic Engine posted:Small Brain: first frontend guy reinventing framework as they go in vanilla JS Can I call $rootScope from inside a jquery ajax callback on an onclick?
|
|
#
?
Jul 28, 2018 00:51
|
|
|
geeves posted:Can I call $rootScope from inside a jquery ajax callback on an onclick? Just make it global and then go nuts.
|
|
#
?
Jul 28, 2018 04:07
|
|
|
I just read the linked page and I think I can understand his reasoning, Its the same argument as with an ORM I guess, all the extra work you need to do to get stuff from the DB when, if you had just learned SQL in the first place, stuff would be lot simpler and faster. SQL is still alive and kicking but NHibernate seems to have lost a lot of love since MS came out with EF. Not saying it is 100% the same for webdevelopment though. Reading the last of couple of posts, I am that guy learning stuff and undoubtedly doing stupid stuff with plain javascript and HTML right now.  Got to start somewhere I guess, otherwise its hard to see the forest for the trees with all the web stuff. Usually this works out though, you come across some repetitive coding work and figure out why you want a framework for some tasks instead of the other way around.
|
|
#
?
Jul 28, 2018 23:47
|
|
|
Mr Shiny Pants posted:I just read the linked page and I think I can understand his reasoning, Its the same argument as with an ORM I guess, all the extra work you need to do to get stuff from the DB when, if you had just learned SQL in the first place, stuff would be lot simpler and faster. SQL is still alive and kicking but NHibernate seems to have lost a lot of love since MS came out with EF. But that's a bad argument about ORMs.
|
|
#
?
Jul 29, 2018 01:09
|
|
|
Ooh is there a React SQL builder? It’d be a wild ride with SQL and Javascript and HTML all jumbled up in a single file, confusing whatever mouldy old syntax highlighter Atom ships with these days.
|
|
#
?
Jul 29, 2018 01:40
|
|
|
Mr Shiny Pants posted:Its the same argument as with an ORM I guess, all the extra work you need to do to get stuff from the DB when, if you had just learned SQL in the first place, stuff would be lot simpler and faster. That's a pretty bold assertion.
|
|
#
?
Jul 30, 2018 04:16
|
|
|
a hot gujju bhabhi posted:That's a pretty bold assertion. That is what I was getting from his post. Maybe I read it wrong, but I read the just use CSS HTML etc. etc. as just use SQL like a lot of arguments against an ORM. Mr Shiny Pants fucked around with this message at 08:33 on Jul 30, 2018 |
|
#
?
Jul 30, 2018 08:27
|
|
|
Mr Shiny Pants posted:I just read the linked page and I think I can understand his reasoning, Its the same argument as with an ORM I guess, all the extra work you need to do to get stuff from the DB when, if you had just learned SQL in the first place, stuff would be lot simpler and faster. SQL is still alive and kicking but NHibernate seems to have lost a lot of love since MS came out with EF. NHybernate and Entity Framework and all that stuff are great products. What unfortunately happened is that the underlying architecture of a product is generally dictated by the structure of the organization, so if you have, say a database team, it'll become it's own monolithic organization, and many organizations that made the horrible mistake of using, say, Oracle as their back-end database ended up with scores of Oracle dbas, programmers, and a generation of legacy databases. EF is great if you're doing a database from scratch and don't have a database team, much less if you have to adapt a ten year old database designed by people who don't understand 3NF and that there are other datatypes besides varchar - however most of the entity framework applications in the wild ended up being "make a lovely legacy application/database use EF" and EF got blamed for the original design being lovely, to say nothing about idiots who would find a slow query, and both rewrite it in standard SQL and somehow conclude it was writing the sql that hand that fixed the problem as opposed to, you know, having an index on the column that needed it.
|
|
#
?
Jul 30, 2018 09:07
|
|
|
Bruegels Fuckbooks posted:NHybernate and Entity Framework and all that stuff are great products. What unfortunately happened is that the underlying architecture of a product is generally dictated by the structure of the organization, so if you have, say a database team, it'll become it's own monolithic organization, and many organizations that made the horrible mistake of using, say, Oracle as their back-end database ended up with scores of Oracle dbas, programmers, and a generation of legacy databases. EF is great if you're doing a database from scratch and don't have a database team, much less if you have to adapt a ten year old database designed by people who don't understand 3NF and that there are other datatypes besides varchar - however most of the entity framework applications in the wild ended up being "make a lovely legacy application/database use EF" and EF got blamed for the original design being lovely, to say nothing about idiots who would find a slow query, and both rewrite it in standard SQL and somehow conclude it was writing the sql that hand that fixed the problem as opposed to, you know, having an index on the column that needed it. Good points, I was merely commenting on the fact that, as pointed out in the link, when a framework goes out of fashion all your knowledge is essentially worthless because a lot of that knowledge is tied to a specific ORM implementation/framework and how it handles stuff under the hood ( query plans, architecture, do's and don'ts etc. ). Whereas the underlying technology is still the same SQL. So you could make a point that if you had just learned the underlying technology instead of trying to pretend you don't persist to a relational model you'd be better off in the long run. Not saying an ORM is useless it's just that there is a lot of stuff written about them and I thought the point he makes has some overlap with criticisms I've read about ORMs. Or I could be misunderstanding the whole thing, it happened before.
Mr Shiny Pants fucked around with this message at 10:49 on Jul 30, 2018 |
|
#
?
Jul 30, 2018 10:38
|
|
|
I do have a question, I am writing some simple pages and do some Ajax calls in the background to retrieve some data from my server, like the user details for the currently logged on user. Where do I put this data if I need to reuse it and don't want to do a request every time this data is needed? Can I just put the data in a Global? That sounds not quite right, on the other hand it is just one piece of data which is unique to the page and which won't be changed but I need it in quite a few places.
|
|
#
?
Jul 30, 2018 10:43
|
|
Mr Shiny Pants posted:I do have a question, I am writing some simple pages and do some Ajax calls in the background to retrieve some data from my server, like the user details for the currently logged on user. If you are using React, you can put it in the top component, and use the new Context api to pass it down. If you are going to have a lot of state like this, you should consider learning Redux, or some similar state-handling system. SimonChris fucked around with this message at 12:54 on Jul 30, 2018 |
|
|
#
?
Jul 30, 2018 12:51
|
|
|
Mr Shiny Pants posted:Good points, I was merely commenting on the fact that, as pointed out in the link, when a framework goes out of fashion all your knowledge is essentially worthless because a lot of that knowledge is tied to a specific ORM implementation/framework and how it handles stuff under the hood ( query plans, architecture, do's and don'ts etc. ). Whereas the underlying technology is still the same SQL. So you could make a point that if you had just learned the underlying technology instead of trying to pretend you don't persist to a relational model you'd be better off in the long run. If only it was possible to learn two things.
|
|
#
?
Jul 30, 2018 15:14
|
|
|
I *almost* have my Gatsby v2 site working with S3 and Cloudfront. Static sites are great and all, but you do have to reimplement a lot of things that traditional webservers make quite a lot easier. The last thing I need to figure out is why Cloudfront isn't gzipping my assets. Going through all of this does provide more context as to why static site services like Netlify exist and why they're worth it.
|
|
#
?
Jul 30, 2018 15:58
|
|
|
Mr Shiny Pants posted:That is what I was getting from his post. Maybe I read it wrong, but I read the just use CSS HTML etc. etc. as just use SQL like a lot of arguments against an ORM. Well yeah, I mean you can compare the two trains of thought in the sense that they are both very ignorant. Mr Shiny Pants posted:Good points, I was merely commenting on the fact that, as pointed out in the link, when a framework goes out of fashion all your knowledge is essentially worthless because a lot of that knowledge is tied to a specific ORM implementation/framework and how it handles stuff under the hood ( query plans, architecture, do's and don'ts etc. ). Whereas the underlying technology is still the same SQL. So you could make a point that if you had just learned the underlying technology instead of trying to pretend you don't persist to a relational model you'd be better off in the long run. Why should you arbitrarily deny yourself access to tools instead of, say, using the tool while also learning how it works? In most cases even using the tool in and of itself will bring about some understanding of how it works as you problem solve with it. Progress is made by building on what others have done before you, not forcing everyone to go through the same hurdles just because. putin is a cunt fucked around with this message at 05:02 on Jul 31, 2018 |
|
#
?
Jul 31, 2018 05:00
|
|
|
So I've spent the last year as an Angular 2 dev and I'm looking at skilling into React as I'm likely going to have to change roles relatively soon and there's 3 React jobs out there for every 1 Angular 2 job so obviously remaining competitive in the market is important. Luckily a lot of the sort of basic principles of Angular obviously translate into React with a few exceptions, like Angular having more out of the box features than React and React & Angular just not being the same loving thing. But it's mostly syntactical things that I'm interested in. So a very basic Angular component might look like this: code:I kinda figure it would be done something LIKE this but it's probably wrong: code:Ape Fist fucked around with this message at 20:32 on Jul 31, 2018 |
|
#
?
Jul 31, 2018 20:25
|
|
|
Ape Fist posted:So I've spent the last year as an Angular 2 dev and I'm looking at skilling into React as I'm likely going to have to change roles relatively soon and there's 3 React jobs out there for every 1 Angular 2 job so obviously remaining competitive in the market is important. JavaScript code:JavaScript code:Lumpy fucked around with this message at 20:55 on Jul 31, 2018 |
|
#
?
Jul 31, 2018 20:51
|
|
|
|
| # ? Jun 7, 2024 17:56 |
|
|
Sorry I meant to template, woops. So what I wrote in React wouldn't work then? (at this point I'm not looking for the most efficient representation, just a comparative one.)
|
|
#
?
Jul 31, 2018 20:58
|
|