g-marcin-journal

Another subject from the set of 97 things that every programer should know is simplicity. The most important thing designing software is to provide client with the functionality tailored to their real needs. Managers dont care about tools applied to obtain requested outcome as long as it gets the job done quickly and satisfy the requieements. On the other hand developers mostly need challenge and constant growth. As a consequence nowadays applications tend to be over-engineered and stuffed with additional libraries, frameworks with tons of configuration. Today ive also watched a youtube video of primagean. It was a comment on article titled "Radical simplicity". It is a reason why id written previous paragraph. The article was about technical overhead that is tend to be introduced within the aplications recently. The one good thought was that nowadays applications are able to do more stuff. The main thought was to use the bare minimum and be careful about introducing new d

Recently ive found good book about programming heuristics. It is a set of short articles giving some advice about how to approach problems connected with design and maintenance of software. The title is "97 things every programmer should known". Each chapter is written by experienced developers willing to share their observations with others. The articles are not specific but gives an overview of the problem and highlights things to pay special attention to. One of the chapters says about refactoring. Firstly it is good to take a step back, define a scope of work to be done and analyse its contents as it is. It is easy to juggle the ideas how great solutions we may introduce instead of existing messy, imperfect code. We all know we are good programmers capable of good design and bold ideas. But in this case i recommend stop thinking about what could be and try to emphatise whith the people who were involved in the process of development of code that we intent to refactor.

  fig 1.1 BehaviorSubject abstraction marble diagram       It is high time to write another part of angular basics revision. Last time i mentioned Subject object. It is also worth to describe other ‚special’ cases of Subject. The first is behavior subject. It is part of powerful tool for reactive programming called rxjs . When writing angular version of exchange app or mars-rover-photos app I was using behavior subject in following way. Start with declaring behavioral subject private field within your service. The following example ilustrates this step: private myDataSubject: BehaviorSubject<any> = new BehaviorSubject<any>( null );     it will declare new private field with myDataSubject name and BehaviorSubject type. The value within <> braces is called type parameter and is a part of TypeScript generic types. In this case it would describe the type of values emited by this subject. on the right side of the assignment statement we can see basic javas

fig 1.1 angular application structure overview      Recently I have been re-writing one of my side projects using another js framework. Originaly written in react, after several days and long hours of scrolling and prompting it was re-shaped to Angular version . In this blog post I want to summarize the stuff I have learned about javascript frontend framework developed by Google . There are only class components. No function component nor hooks available in angular. Moreover it requires developer to use typescript straightaway without support for vanillla js which make it less available for beginners. Angular has no dedicated syntax such as jsx/tsx which enables to combine template, controller and styles within single file. It divides the responsibilities to separate view-template.html file and component.ts file which contains logic. It is a good moment to mention that re-renders of the ui uses diferent technique under the hood. Angular utilizes incremental DOM mechanism a

fig 1.1 redux-principles; <source: Tomasz Ducin presentation on frontend architecture>        Hi, in this blog post I’d like to introduce you to redux which is complex state management tool for web applications. I will describe it from a react point of view but it may be used with other frontend frameworks as well. Redux is recommended to be implemented using redux-toolkit - a set of utilities which facilitate developer experience during redux logic implementation. One of redux-toolkit authors is Marc Ericsson (that guy with simpson avatar) To begin with we need to install three packages: react-redux, @types/react-redux and @reduxjs/toolkit. The next step is to create store. Store instance is initialized with configureStore({reducer:{<import your 1st reducer and put its name here!>}) utility. It is also a good location to declare types for rootState(may be called App state) which is main representation of the application state and dispatch. The following snip

     fig 1.1 react-context scheme ---------------------------------------------------------------------      One of the way of sharing/transporting data between react components is context . In comparison to props drilling it doesn’t require you to pass the data through all of components until you reach the desired one. Context allow you to describe the data in single place and get it in another. Lets look into how we can apply context to our react app… At first it is good to create /contexts folder in as a subfolder to /src folder. This will be location of all of the future contexts as there can be more than one context per app. The next step is to create the .jsx / .tsx file and create an instance of context by assigning a createContext() function call to a variable. createContext function require to pass defult value of the context which will be used in case user will not specify the context value.. Please be advised that it should be done out of the function component –