JS be fun!

Well. Imagine that I would have simple microservice that is small Express application that serves data from DB and transforms it. First I would think about proper design of code. I would split code into: initialization part (creating Express app) - smoke tests would be sufficient Express endpoints - they will be set appropriate headers and integrate logic and DB. I would tests more overally - if headers are correct etc. logic - this is meat, so I would test more thorougly this. Logic would be probably in pure functions. Easy to test. (that's one of reasons I don't want to put to much logic in endpoints themselves because they are harder to test). wrapper for DB - I would test e2e with some kind of development database in play. Maybe I would also make some kind of automatically generated tests for endpoints. I mean. I would already test logic so no need to duplicate code, but to ensure that endpoint really returns logic. I would probably make functions l

From what I observed React context is used in many ways: As simple value (e.g. string, number, boolean) As object As immutable object (i.e. if you want to change something in context you trigger appropriate update to component which render Context.Provider As mutable object (i.e. if you want to change something in context, you mutate context directly. I usually work this way that have main app context which is mutable and contains some "global" variables and some methods for making global changes. I think mutable React context is harder to maintain. And context always sounded like some escape hatch for access/write to global state. And I usually won't have too many contexts. In small app there would be one React context. In bigger apps I could think about some others, for some specific parts of app or maybe for some specific aspect of app (e.g. UserContext, ToDoContext etc.) And context for me means usually object. In React do

You don't need Redux or any management system in React. You know this, right? Right? But seriously people usually when they don't use state manager, they just use useState and context. And it can be sufficient. But not always. Sometimes you need global state management, but Redux and different state managers are just inconvenient They force immutability (you can mitigate it with libraries like immer, but still). They often force you to use some kind of actions What's your options? If there was a way that would allow to use plain JS objects and classes for state management. Wait? Do I mean Mobx? Well, conceptually, yes. But the truth is you don't need ANY library for this. Mobx just wires JS objects to updates. But the thing is you can do this your self. Just write normal JS classes and put reactivity into them. You can know think that's reinventing the wheel, but I will say it's super simple: class Entity { subscribers = []; state = {};

Entity... it's a word that it's often related with Domain Driven Design, but I won't write specifically about DDD. What I want to write, can be used without DDD approach. I think DDD is somewhat conceptual heavy and it's often useful to use terms popularized by DDD but without all this weight. So. What's entity? Let's assume it's a JavaScript class (actually it doesn't have to be a class, it's more conceptual term, but now I assume some specific implementation of this). So... each JavaScript class? No. It's more like something that has specific identity. e.g. User, Product. Usually you have many things of some type (e.g. many users), but this concrete user (represents in database by specific row, but in app you would create instance of User class for example). On the other hand if you have something that is more of a utility class - e.g. imagine that you have Theme class with colors, backgrounds - this thing is probably not entity (thou

how to organize React project to ensure maintainability? separate configuration - instead of putting all in your "normal" files (e.g. files with React components), it's better to put "configurable" things in separate file. What's are configurable things? E.g. urls for API endpoints, route names, translations etc. dev mode - it's useful also separate your configuration for debugging or testing from the production one. You could also have some feature flags somewhere in your app to enable devs to comfortable debugging e.g. special buttons for doing something useful for programmer, that has no sense whatsoever in production mode. Sometimes it's useful to have some "sandbox" views. separate components into files - rule of thumb can be thought as "each component in different file" but this has not always to be true. Sometimes you could put multiple smaller components in one file if they are related/part