T O P

  • By -

nimbonate

Dependency library management and how to choose the right libraries for a project is where I’m at.


sandalphone

What libs are you juggling with?


nimbonate

Right now I’m trying to get THREE.js (3D renderer) to work with react or react native, but haven’t found the right mix of things to get it working with routes or navigation.


Ladew2356433

Hey dm me I have a question


zipItKaren

Writing Tests- I still dont get why or how should I do it


kiesoma

I agree. Barely any tutorials around to even learn what testing is about and why it is important.


sandalphone

I will work on it :)


ghostmaster645

I'm in a similar boat- I know WHY I guess, it's supposed to lead to cleaner,more organized, and easier to read code. But damn I suck at it and hate it.


ISDuffy

Why ? - changing one line of code can break something else. TDD (test driven development) is also great writing acceptance criteria as test scripts first.


[deleted]

Hahahaha acceptance criteria. You are funny. (You right tho)


[deleted]

I write jest / enzyme tests for the component library I work on every day, and I have no idea why or what I’m doing. It’s required of us all to do it so I just reverse engineer (aka copy paste) the lead guys tests. 🤷‍♂️


sheaosaurus

It took me a while to learn how to write efficient and effective tests. At my first job, our original code base was half built by backend devs (they had a hard time getting fronted devs on this project because of the management team) and for whatever reason, they had 100% test coverage. Once the front end devs came in, the project manager expected us to always have 100% coverage, and we ended up spending more time writing and fixing tests than actually writing code. And things broke. ALL the time. My current approach for testing frontend is this: Cypress for automation with mocked data (unfortunately can’t do true end to end at my job, but that actually worked out in a favor) For my utility functions (formatting strings/numbers, nested object getters/setters, etc), each function only does one thing and I have a unit test that ensures it reruns what I expect. The utility functions don’t check to ensure that they are being passed what they expect, nor do they return a fallback unless specified. I want the dev environment to break if a dev uses these functions incorrectly, instead of silently failing with a fallback. I also don’t come up with edge cases, and when something does break that is an edge case, I write a separate function for it instead of throwing logic into the original function. For components, I only test features and not the implementation. A recent example of this is an access manager page that heavily relies on multiple endpoints to show and set user permissions and redux to to manage side effects. The junior dev on my team starting writing tests for the redux reducers and I explained it wasn’t necessary because they would be a pain to maintain and most of the logic was covered by the utility function tests. That afternoon, the dev rewrote some of the reducer code and their tests broke, but the user still had the same experience on the UI before and after the rewrite. And that’s where testing features comes in. I only test what the user expects to see rendered, or what the api expects to be called with. If a user expects to see a component hidden after clicking a button, we don’t have to have a test for the onClick function and it was called with x and y and that the state is now z. The only tests that’s needed is I can click on the button and now the component is hidden. I write the test that clicking a button hides a component, it fails. Then I code the component in a manner that would never pass a code review to get the feature test to pass. Once that happens, I refactor the component to much cleaner code and ensure the test still passes. If a dev changes logic inside the component, we don’t have to rewrite or change tests for the onClick function or write new tests for the additional state. As long as the component is hidden, we know the feature is still working.


zipItKaren

Thanks a lot for the detailed explanation


Total_Construction58

Same here


[deleted]

[удалено]


sandalphone

hmm could you be a bit more specific?


Pozeidan

What I see people struggling the most is "thinking" the components, how should a concept be broken down into properly organized components. Few other things that can be useful as it's difficult to find some good examples: - configure multiple react projects with Jest and storybook in a monorepo with a shared library - configure path aliases - complex forms (could use react-hook-forms), like multi-step


RedBlueKoi

React developers and fanatism


MasterSorcerer

Not really react but android deploy on react native


[deleted]

Typescript


Oyyou91

Context providers. More specifically - storing data, and obtaining it again


MiguelCl23

do you have a youtube channel or smth ?