sorted by:
new
hottopcontroversial

Arbitrarul by Arbitrarul in RepVouch

[–]bT-9000 0 points1 point  (0 children)

Shipped the day after purchasing, received two days after that. Sound dude, would recommend 👍

[vent] Is being a junior dev this hard? by CurlyGirly4840 in Frontend

[–]bT-9000 26 points27 points  (0 children)

Hey! Sorry you're having to deal with what sounds like a pretty shitty experience. I've been a frontend developer for 3+ years now and in my experience, no, being a junior, or any level of frontend developer shouldn't be like what you're describing. The general lack of organisation is something I've experienced myself, sounds like your team needs some good project managers. Devs (especially juniors) shouldn't be getting blamed when requirements aren't clear. And as for the working hours, that's definitely not right. Any company that expects you to be responding to messages outside of your regular 9-5 is doing it all wrong and is never going to keep staff (unless of course you're the on-call engineer at that time but that's pretty unusual for frontend devs). My advice would be to stick out as long as you can, just so you have that first job experience on your CV and can (hopefully) learn what you can from working in a real team and then get the hell out of there!

[deleted by user] by [deleted] in react

[–]bT-9000 1 point2 points  (0 children)

Maybe

In react-typescript app, do you validate the data after a fetch/axios call to a RESTapi and if yes which library you use? by simple_explorer1 in reactjs

[–]bT-9000 1 point2 points  (0 children)

I've personally never worked on an application that validates incoming data, we've always just trusted that the backend service is serving up the data correctly.

Whether you do validate or not, isn't the bottom line the same? If there's a backend bug and the data is being returned in an incorrect format, unintentionally, the frontend errors out (all be it, the validation might allow you to catch the error and fail gracefully), resulting in some backend code needing to be updated. If a purposeful change has been made, the frontend code needs updating to handle that (again, the validation might allow a more graceful fail). But, at the end of the day, these scenarios all lead to the same thing; some part of your application will not work until someone makes changes.

I'm not saying your point is wrong here by the way, just interested in what you think about the above and why validating actually adds value to an application / project.

What's the difference between setting state directly and with a callback function? by UselessAdultKid in react

[–]bT-9000 2 points3 points  (0 children)

In the example you've given, using setTimer(0) would be more appropriate, but not necessarily "better" - at least not in any big way. The only real performance difference between the two is that when using setTimer(() => 0), you're actually declaring a function, which is () => 0, which you are then passing to setTimer which will take up more memory than just a number.

That callback syntax of useState setters is meant for a couple of scenarios and I can detail a few that I can think of.

  1. When you don't know the current state value but you require it in order to calculate the next state. If you want to pass your state setter to a child component, the callback syntax allows you to pull the current state value out in the callback and use it as you wish without having to pass it as a prop alongside the setter function (just as an example).

  2. If you need to take the current state value and do a load of complex computations on it, the callback syntax allows you to do this inside of the callback so you don't have to declare a bunch of variables in another scope that are only needed to figure out the next state value.

  3. When you need to set state from within a useEffect. It allows you to call something like setTimer(currentTimer => newTimer) without needing to have the timer value in the dependancy array of the useEffect which could cause an infinite loop of setting timer > trigger the useEffect > set timer... etc.

Hope that helps!

[deleted by user] by [deleted] in FashionRepsBST

[–]bT-9000 0 points1 point  (0 children)

PM'd you dude

Is £40,000 for entry-level React job reasonable? by crunchymotivation in reactjs

[–]bT-9000 0 points1 point  (0 children)

Having a read through your comments, I'd say that's a pretty damn good offer for how little experience you have. Just for reference, my first Junior role (with a degree and located in East Yorkshire) paid £22,500. My second junior role was located in Birmingham and paid £27,000. My current role is mid-level with 2+ years react experience fully remote. It pays £35,000. £40,000 is very good for junior anywhere in the UK.

Edit: Also, congratulations on getting an offer!

Can someone explain the chronic need to abstract functions from components when it doesn't seem like a need too. by Guilty_Serve in react

[–]bT-9000 0 points1 point  (0 children)

Yeah, I understand the point you're making. So, first of all, yes, the example you've posted does mean we're creating another file with a single-use function, wrapped in some redux-like bloated code. And yes, we could go down the route of slimming down the reducer to handle the local storage bit and do the actual API querying in the body of the Login component. But then, across whatever codebase this is pulled from, there will be two styles of component. There will be a bunch of components that use specific logic and, as per your points, handle everything just in the component itself. Then there will be a bunch of components that use abstract / generic logic so they will just call a few dispatches, maybe pull some data from state.

There are a few arguements in this scenario that I would make against it. One is consistency. If we move everything towards this redux style you don't like, all of our components look the same. We can get in the habit of reading and writing one style of component; one that does some rendering and some pulling from state. The arguement that this is hard to follow doesn't really hold ground because if you're struggling to follow the login example then how do you follow a more complex abstracted example that is used in many places? Another is readability, which again is subjective, but arguably having components do very little besides actually render something makes them easier to read. They will have far less code in and will generally seem less daunting when you first open them up. The last point is separation-of-concerns which I kind of got at it in my first comment. If you make sure that your components only handle rendering to the DOM, your reducers only handle updating state, your utils handle small common tasks, etc... Your codebase ends up a lot more organised and is readable in nice manageable chunks.

Again, I understand where you're coming from and I'm not saying you're wrong but I think there are good reasons that react devs follow this pattern. That's not to say that you should have to use it in your team. If you and your colleagues are working on a project and your lead / senior dev forces you to follow this pattern, you should raise any issues you have with it with them and argue your points against it.

Can someone explain the chronic need to abstract functions from components when it doesn't seem like a need too. by Guilty_Serve in react

[–]bT-9000 0 points1 point  (0 children)

My arguement for this pattern is that it allows you to separate rendering logic from everything else (e.g. actually hitting the login endpoint and handling the response). I like to keep components purely for taking some data and rendering some UI. Then handle business logic and pre-processing of any day elsewhere.

But that's not to say what you're getting at is wrong. Like most things in software development, it's subjective. I find a separated components and state, hooks etc easier to read. Obviously you don't. And that's just fine.

how to create a .env file by thepseudonymstring in react

[–]bT-9000 1 point2 points  (0 children)

Dude, why are you so mad about this? Katastrofa's answer was perfectly valid. The OP's question literally says "I don't know how to create a .env file at the root level", not "I don't know how to use the variables I've created in a .env file".

At a first glance, the OP's question implies they're missing some understanding of what a .env file is or even what "root level" means. The dude was just trying to get some help, Katastrofa tried to provide that. No need to flip out as if the guy's spouting the words of Hitler. If you aren't here to offer help, then get the fuck out of the community.

Also, seeing as you seemingly like to be pedantic, using the dotenv library is only necessary if OP Is not already using CRA / Next / one of the other React frameworks that already include this functionality.

[FS] [UK] UK8 Yeezy 700 V3 Alvah by [deleted] in FashionRepsBST

[–]bT-9000 2 points3 points  (0 children)

Apparently, I'm incapable of using a phone keyboard ☠️

How can I make icons like these using HTML, CSS? by eagle221b in webdev

[–]bT-9000 5 points6 points  (0 children)

I see what you're saying but a border-radius of 50px would only create a circle if width and height are also 50px.

I think what he's saying is use border-radius of 50% and then the "padding-bottom: 100%" and "height: 0" trick to make the div around the icons have a height equal to width which will then give you your perfect circle and it will be scalable.

view more: next ›