iagorodriguez

I was not emotionally prepared for this level of humor today, its Monday, please!

wouldn't this be a good thing? I prefer my circadian cycles not to be disturbed by artificial lights and if i am reading this right, it is what happens with led lights. this would be different of course if i had no access to natural lights. glad to be corrected :)

Amazing job by an amazing developer!

Nice platform, are you planning to add support for custom maps?

Thanks!

Sorry but... what is it an implicit area? What are their benefits?

Thanks to you for taking the time ro reply back :).

I am a rails developer myself and I love rails, but this applies to rails too. Actually rails lowers this problems a little because it is an opinionated framework but you could same to Angular for frontend. In react case, you just have to build that yourself with the pros and cons.

Innovation doesnt come from adding a library to the package json. You are a member of a big team, not a single dev on a pet project. Innovation is on the product, not in your developer experience (unless you are creating a developer tool). Consensus to make big decisions is not the way to limit your developer skills is the way to align a team to achieve a common goal. :)

The problem is not about react or not react, the problem is how to align big team to create an application. If a big team is going to be working on it you need some strong opinions around it. Do not mess with the package.json. I cant stress this enough. Actually, the most important file in your whole application is the package.json. Almost nobody should be allowed to add additional dependencies because is the main point to generate chaos and problems in the long term.

Also, the design system matters a lot. Have a small team working on the UI components to tailor and extend the design system. Dont allow the rest of the teams to extend the ui components with new libraries. Stick with the design system as much as you can. The rest of the teams should minimize the amount of CSS they have to write to components placement.

Usually the datagrid is the soul of any enterprise application. Choose it wisely and be sure it covers as much functionality as you can and also that it is customizable on an "easy" way. There is always a team with the need of a datagrid that sorts, groups, filters the data with dynamically adjustable cells and multi header items without pagination. Welcome to hell.

Use one pattern: hooks, central store, whatever you want. If at some point you have to change it you have to know which teams are using which one. Dont allow team members of the same team follow different patterns. Code reviews must take care of this.

Hope this small tips help one or two teams out there. I have worked on the migration of 5 big enterprise applications from angularjs to react or from legacy desktop application to react or from server pages to react.

I made a lot of mistakes that costed a lot of dollars. I have tried to learn from them. Also, dont take me very seriously, I am pretty sure I am about to discover another mistake I have made.

It depends on how effort do you want ton invest on your data visualizations. If you are looking to create a dashboard with some charts and not very specific UI requirements on them you can use a data viz library (recharts, vega, C3, highcharts, ...). If you need to go deeper with more specific requirements on the charts ui, the interactions with other UI elements and/or optimize for high volume of data D3 is the best path. If you want to create your own unique consistent experience you would probably even invest on your own library on top of D3. You can have the base of that library in 2-3 months period with the basic charts: barchart, linechart, scatterplot, pie, ...

I run a small dev company. This is the first lessons we teach our programmers. If your code cant be understood by someone else with minimal efforts it is not good enough.

If you create a form to submit new searches I will definitively help you (Cómo votar a Trump si eres mexicano)