Good writeup, useful information!
Hm. Interesting library indeed, but somewhat weird tutorial. And even if it made some sense, please never name a setter function "get" anything:
const [protectedPage, setProtectedPage ] = useState(false)
const getProtection = (protect)=> setProtectedPage(protect)
Since there already is a setter, why make a redundant new one and name it confusingly?
Couldn't find comment function on the article, thus my comment is here..
Might seem fun or stupid reading stiff like this in spare time.
But I actually turned down a job offer once because they made tests similar to these. I actually did quite well, but when I asked why the f**k we're doing this, and the guy said something like "well this stuff happens in real code all the time, and a good programmer should be able to spot it"... Well. I believe he even said an "intelligent" programmer should spot it.
With at least somewhat decent developers, stuff like this does _not_ happen.
And if it actually does happen in a company or team, then i surely wouldn't want to work there :) But I'm pretty sure such tests or quizzes do not reveal much about a developer's quality in real software life.
I wish word order mattered :)
Nope. He keeps posting new c++ links.
Looks nice. I'd recommend more explicit naming for all config files based on main and renderer, For example, currently the renderer tsconfig is named just tsconfig.json, while the tsconfig for the main process does have a more special name. Simple and clear naming with main and renderer everywhere would be better, and in some cases there may be a third one, a base config, that both extend from.
Additionally I'd set up more aliases. I'd make a tilde alias to the src dir, so both main and renderer may import from it, and finally, I'd make the @ alias work for both processes - in renderer code it should point to src/renderer, in main code it should be its own alias to src/main.
Good looking setup otherwise, well done!
I think the `* 1e4` trick is far less readable and understandable than the `en-GB` one :)
Yeah it's purely cosmetics. I saw a colleague set color and icons for his backend and frontend terminals manually. And it looked nice and helpful, but I couldn't consider it for my self unless it could be persisted and automated in the project settings.
Does anyone know how to persist icon and color settings for terminals?
It seems to me you must always do this manually, which stinks if you frequently kill and restart terminals.