51–60 of 75 posts
Front-end has gone completely off the deep end. I'm looking at the source code and there must be 4 or 5 dozen modules, totally 5.1kb gzipped! And as far as I can tell all it does is copy el.value onto an object. What ever happened to care in our profession? What happened to putting the users first? If you are adding 5kb of overhead to your website for this , it is criminal malpractice.
I’m going to hijack to request some help understanding whether hooks are a good thing or.... a mediocre thing I just have to accept. Here are my questions: 1) Is it just me or so hooks really push you to commit to either “state comes from props” or “state is held internally” but you REALLY can’t mix the two? So, if I have say, a searchable select box, I must either A) be stateless, and let some other part of the syst…
2)There are several points, but I think the most important one is simply just to save time instead of using useMemo as passing callback to child components is pretty common. And yes, it is the same. The official docs literally said that. useCallback(fn, deps) is equivalent to useMemo(() => fn, deps). [0]
3)You can call it a hack I guess. If you don't want to wait for rerender, you can keep a value inside a ref! While class component can just create a property, function component doesn't have that. That's where the useRef came in, and that's just one use of useRef. I'm not really sure about the articles you mentioned. I never faced a use case where you would use a state and also keeping it inside a ref, can you share an example link maybe?
For the .current part, since refs is originally used to access the DOM. And the DOM node could change for whatever reason. To access the node, we use .current.
4) It depends, but I don't think keeping two things in sync using useEffect hook is a good idea. I'm not really clear about the issue, so I can't say much.
After using React for a while with class and lifecycle, I think all the available hooks is really nice. Feels like we got a fresh wind while developing with React. Using hooks and not have enough contrast to make me feel I can no longer code React without hooks. They let you reuse and share the same logic for different components or projects easily. Less code to read, and for me, functional component with hooks is way easier to read compared to a class component.
Refs: [0] https://reactjs.org/docs/hooks-reference.html#usecallback
Front-end has gone completely off the deep end. I'm looking at the source code and there must be 4 or 5 dozen modules, totally 5.1kb gzipped! And as far as I can tell all it does is copy el.value onto an object. What ever happened to care in our profession? What happened to putting the users first? If you are adding 5kb of overhead to your website for this , it is criminal malpractice.
I’m going to hijack to request some help understanding whether hooks are a good thing or.... a mediocre thing I just have to accept. Here are my questions: 1) Is it just me or so hooks really push you to commit to either “state comes from props” or “state is held internally” but you REALLY can’t mix the two? So, if I have say, a searchable select box, I must either A) be stateless, and let some other part of the syst…
Hooks do a good job of nudging you to make better decisions about how to design your app, primarily by making bad decisions harder to make. This feels bad initially but once you get it, I think its better.
That said, lets address your issues:
1. Yes/No. There is no reason you cannot have both props and state effect your component, however I don't think thats your question.
If you need something outside the component to effect what is typed into the box, (e.g. the app can clear the text) then yes, you should be passing the text in as a prop, along w/ an onChange callback prop for when the text is changed within the component. I think of it as, if the state can be changed somewhere else then it doesn't belong to the component, and is thus a prop. Note, the options could be filtered in the component or not, also up to you.
2. I agree with this question. The main use I've found of useCallback is to avoid triggering changes to other hooks. ¯\_(ツ)_/¯ I think react team members have even asked about how people use it: https://twitter.com/brian_d_vaughn/status/117435997560009113...
3. useRef is great. It allows you to store state which does not trigger re-renders. This gives you a finer detail control of your component. I would not use it to "hack around the fact that state changes don’t take effect until the next tick" though. I think it would be bad practice to have to think about when state changes take effect. (This might be one of the "making bad decisions harder to make" moments)
P.S. I agree about typing .current everywhere, but it makes sense from a JS perspective. useRef is simply keeping track of an object instance and you are accessing a member of that object. I'm not sure if it has to be 'current' or if thats just convention (anyone know?).
4. I can't answer this without an example. Generally, if you need the value to render, you either have it via a prop or it it is already stored in state. If you need to transform that value in order for it to look right, you do that inside your function. If it is a complicated calculation, do it with useMemo, so it only has to be done if your value changes.
If something causes your state to change, you should just update the value and then allow it to rerender, thus it becomes the already in state case. Those changes should really only be part of other actions though, not your render function itself.
So that was long winded, but hopefully useful. I think hooks are good and generally use the following heuristic: - useState: state which causes rerenders on change
- useRef: state which does not cause rerenders on change
- useMemo: calculated state based on other props/state (only needed if the calculation is expensive)
- useCallback: useMemo for functions :p
- useEffect: Do something based on state or lifecycle of component (e.g. mount/unmount)
(edited for formatting)
Front-end has gone completely off the deep end. I'm looking at the source code and there must be 4 or 5 dozen modules, totally 5.1kb gzipped! And as far as I can tell all it does is copy el.value onto an object. What ever happened to care in our profession? What happened to putting the users first? If you are adding 5kb of overhead to your website for this , it is criminal malpractice.
This looks really good. But is there a non-hook version for use in class components? I'm imagining it might look like this: class MyForm extends React.Component { formState = new ReduxHookForm(); render() { const { register, handleSubmit } = this.formState; return ( male female ); } handleSubmit(data) { console.log(data); } }
Earlier quoted context omitted.
This is like saying that backend's gone crazy because people are loading MBs of frameworks just to print "Hello World" on the screen. Well, yes, but those are just examples, they're meant to be simple to understand, not a realistic use case. React is a tool for building complex web apps and in RL such app would do a lot more things and then it'd start to make a lot more sense using it. If you do something this simple…
> This is like saying that backend's gone crazy because people are loading MBs of frameworks just to print "Hello World" on the screen. They are not equivalent at all, you can add as much bloat as you want on your backend as long as you scale it. The cost is put on you. Front-end bloat directly affects the user. We used to justify every library addition, now people just add a library for every trivial task to make it…
I strongly recommend to automate form generation based on JSON schema what will enable zero coding for maintenance tasks like e.g. synchronization with model changes. As form code is the most important entry point for security flaws in web applications it is also the most expensive and it is not a good idea having to touch production code for every little backend change. This looks like PHP coding 15 years ago. Do no…
In my experience, this is a pie in the sky dream - orchestrating dropdown loading and lazy loading becomes challegning. Dependencies between inputs become impossible (if this field is filled [or set to value x], show this section of the form, if this field is of value x, only allow values of a, b or c in field y). Not only this, but I think generally when a backend change happens you want to be aware of it (and fail…
I strongly recommend to automate form generation based on JSON schema what will enable zero coding for maintenance tasks like e.g. synchronization with model changes. As form code is the most important entry point for security flaws in web applications it is also the most expensive and it is not a good idea having to touch production code for every little backend change. This looks like PHP coding 15 years ago. Do no…
I'm in the process of ripping a system like this out of our main onboarding application. The idea sounded so great: "Just add another object to an array and the form field will magically appear with validation, persistence, etc". The reality is that business requirements turned it into a ton of special case "if" statements. I'm going to avoid that for the next go-round.
Front-end has gone completely off the deep end. I'm looking at the source code and there must be 4 or 5 dozen modules, totally 5.1kb gzipped! And as far as I can tell all it does is copy el.value onto an object. What ever happened to care in our profession? What happened to putting the users first? If you are adding 5kb of overhead to your website for this , it is criminal malpractice.