467 karma · joined July 8, 2015
I feel like JS gets thrown under the bus in discussions, but no body talks about arcane file structures in Java or implicit pathing lookups which have the same kind of "historical path dependence" to why they exist as JS has for require/import.
All languages have their warts and 99% of the time they're all doing the same thing just in slightly different ways.
However, it becomes scary when the people with access are much less level-headed. There are people who think gay people or watching porn should require treatment. There have been power changes where people with drastically different views have an agenda to push, and your innocuous "not really that bad" is all of a sudden an imprisonable offense because you "think differently" and you might encourage others.
Questions get grouped into 3 groups and you get a numerical score... literally it only says "Result: 22". No scale, no units, at best there is maybe a color scheme green, yellow, red? (maybe? not for me)
At least the groups have descriptions...
I got zero info from this, it was a waste of time
>This is a read-only view of real growth data from a Saascast customer — don't worry; they don't mind sharing it with you!
I wonder if it'd be easy to tell based on the payment amounts and whatnot who the customer is!
1. Why hire a team of non-webdevs to do webdev. (on 2nd read, it appears they wanted to use the same team from the WPF app... ¯\_(ツ)_/¯)
2. If you build and treat React components and their APIs as the abstraction layer, then they're just components... who cares how they're implemented.
3. Just because the existing project is big, doesn't mean your new one has to be... split it up!
4. Redux... the root "technical problem"
My hot take is that the authors technical issues probably come from Redux and not React. Using redux as the core of your application is like pouring glue on a lego set. In an ideal world this is great because everything is strong and well defined. In reality, it prevents flexibility and applies hard constraints to the entire system.
That one choice of using redux effects the decisions you make in every component. You lose flexibility to encapsulate features and experiments. You're forced to bend over backwards to do things in specific ways.
Redux is the JS equivalent of the Windows Registry.
The truth is, you're contributing back to people and the system which let you make and run a business that makes millions starting in your 20s.
> the most an attacker can do is to change the content.
Sure , but I would argue, depending on on the content, that malicious content can be just as bad as malicious code. Just ask anyone who has been phished.
There are other comments about political feasibility, but what if the same system became a way to re-produce the tax for use we originally built into gasoline.
Obviously theres a bunch of tax evasion / self charge cases that would need to be considered.
Astroturfing, on the other hand, is when an outside influence is actively trying to organize spread out groups to make it look like a grassroots campaign.
Believe me, I agree to an extend its a matter of taste, but I too like that my underlying understanding of whats happening under the hood can be followed by a raw debugger without following string based mappings.
In react I can set a debugger endpoint right before the return of render and see what all my local variables are... is anything like this possible in vue?
All of them are approaching the same problem from different directions and paths. If each discovers something new and useful, the others can decide if it would be a good fit for them.
It's all wins all around, so I don't understand the disparagement.
I'm mixed on vue because of the string bindings. I really like to know where my variables are coming from and really hate when two dependent uses but not actually the same thing...
That said, I'm happy to re-evaluate my stance... so what does it mean to be "the same thing"? I suppose in the past, I would say that the compiler thinks the things are the same, and it would be easy to change either:
1. If it is a value, I can set/change it in a single spot
2. If it's a token, it is easy to detect and change everywhere, and tooling will help my avoid misses.
That said, in React, if you were to mess up a 'token', the runtime would be very upset and it would be hard to have something like `onClick={incremant}` (note the a). Tools would make it super easy to spot.
What does vue do if you miss-type your bindings?
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)
I recently read somewhere that for backwards compatibility reasons no new element types can be added within `head`. This causes a lot of overloading on the existing ones for elements like <link />.
I don't have any supporting evidence though.
Surprise! You need to know the basics of how your language works.
People are buying and selling at huge values, and maybe winning a little here and there on upswings in the market, but the banks win either way with their steady monthly payments.
It feels more like an ad than news.
The problem is that the credit system was not designed for society, it came out of a business need. In reality, you don't need a good (or any) credit score if you don't need a loan... but if you do need a loan, the person giving a loan wants to know if you're likely to pay them back.
The credit agencies decided they were scummy enough to collect as much personal info as they could, and sell it to those companies so they could asses that risk... When you get a full credit report, its actually data about you and your accounts, the score is just the distilled version of that data to make it "easier".
Finally, credit score is not always the last straw, depending on what kind of business you're working with. Many smaller companies might be willing to work with you regardless of your credit score, however, they might adjust the terms of the deal...
I don't think "dark theme" is always the right answer, but I think with a new medium, a new basic is worth considering.