Writing CSS styles is an essential for frontend applications, but CSS doesn't scale well. The lack of namespaces or types makes writing styles for complex applications error prone. Luckily multiple solutions resolve these issues and work well with React.
The most valuable features I've ever created were the ones that had a clear objective for their implementation, and the entire team had complete control over their tasks throughout the development process. A well-executed refining stage is a major factor in the rest of the process running smoothly.
Software development isn't just writing good code. It's also about whether the right features are being delivered at the right time.
Splitting the application logic and business logic has been long a good practice in frontend development since it eases up changing and testing each part independently. The same can be also with UX logic and design.
Splitting the application logic and business logic has been long a good practice in frontend development since it eases up changing and testing each part independently. The same can be also with UX logic and design.
Optional Chaining is one of the most requested features in Javascript (and Typescript) which is no wonder since it solves a very fundamental problem; accessing the property from a dynamic deep object safely.
Abstraction is a result of a process to generalize the context and arrange and hide the complexity of the internals. The whole computer science is based on this idea and if you are a front-end developer, there are multiple layers of abstractions already under the code you are writing. Abstraction is a very powerful concept and it speeds up development hugely if done correctly.
There are more than enough options when deciding a toolset for building the common components in React. In this post, we are going to explore how to build common components with CSS and SASS and what kind of benefits and pitfalls there are.
Earlier in this series, we have gone through how to create your component library with different methods. Besides the tools to create the components themselves, documentation and testing create a lot of value to your library. Components in React consist of three ideas; understanding each state of the components, understanding the transitions between different states, and understanding the interaction in a component.
Starting to create a common component library with a ready-made component library bring the most value in the beginning. These component libraries usually include some set of frequently used elements on the web and also give a chance for theming to speed up developing.
CSS-in-JS is a wide term that covers a lot of different practices that enable us to write styles straight to React components. Combining style to functionality gives a lot more flexibility to write state-dependent styles and this also fixes the issue of having the only one namespace.
A common component library/design library is a set of visual components that builds up a base for the application. The library usually includes Typography elements like headings and paragraphs, form elements like buttons and input fields, and page elements like tabs and accordions. These can be implemented inside the project or as a separate project.
Recently I have needed to solve a problem that involves generating a PDF file based on database content. Since these PDFs are not generated too often, it doesn't make sense to 24/7 running service. Luckily both Google (Functions) and AWS (Lambda) have an event-driven service which is only running on request.
There is no such thing as 'no tests' when talking about productive software development. The code will be tested all the time by the customers. You can either rely on them or test it yourself. The fastest way to test your React project is to use automated testing. Here are five tips about how to make it productive.
One of the biggest reasons I like about React is that there are very few restrictions on how to do things. This also includes the structure of a project. This freedom also has its downsides. Choosing a poor structure may cause some trouble once the project starts to get bigger. The most commons signs are that the changes in one component will break multiple unrelated features, and creating comprehensive tests starts to be impossible.