First 250 days of software dev - Part 14

Day 131

1. First of all, I looked at what a context is all over again. In a tree, a prop normally has to pass through every part and knot in the trunk to get from the root to the branch at the end. But having to go through all of this data (prop) can increase the complexity considerably. Context provides us with a global data (state) that can be accessed by consumer components accessing the provider.
2. Component is basically like a JavaScript function and prop is input. State is similar to prop, but it is private and controlled by component. When the state is updated, re-rendering occurs. Components are like a gift that React has given us. They are the building blocks that enable code reusability. Let's imagine we are writing a button component. On every page where a button is used, we can use the same component instead of writing code for the button over and over again. We can also create different variations of the same component. By using different variations of the same button component, we get a consistent design (Unrelated and overlapping buttons on each page will provide a dirty and inconsistent look. This should not be the unique design of the application that stays in the memory).
3. Afterwards, with your advice, just like creating the architecture of a website project, readings were made on how the react project should have an architecture, folder directory, design pattern. As with web project architecture, there is no single right or wrong here, and everyone's best practice was their own approach. Two designs in particular were frequently mentioned: There was a project architecture where components were built with an atomic structure (atom-molecule-organism-template-page). Here atoms were the smallest building block components that could not be broken down into smaller groups. Molecules were a group of atoms that did one thing. It can be thought of as a form field. Organism was a structure made up of molecules that made up the more complex part of the app. Template, as the name suggests, was the layout, the template of a page (Illustration: The template of an object is the class. The page is the instance of the template). Another common design was the Container/Component concept. The logic was to make components as stateless as possible and see them as "dump". Container was acting as both a controller and the page itself. There have been many disadvantages of this issue in the past and now there are optimized solutions for it (applying command pattern from design patterns, developing with the help of hooks, etc.), but since there are different applications and it's late, I think I'll talk about it later. But in the reference sources where atomic design is explained, issues such as the container/component concept is not scalable, it is not clear what it does (is it a page or a statful component acting like a controller) are mentioned and it is said that there is no need to use it. On the gray side, both of them have a lot of users and it would be useful to create a design according to which is most useful for us and which will cause less problems in the future. The options can be not only two but a completely different structure.

A resource that doesn't go into these detailed nomenclatures and explains React quite well, frankly, caught my attention more: React project architecture.

SRP translated to react native: "A component or a hook must do one thing, do it well, and do it only."

Again referring to the link above, I take the following sentence directly: "You should create a separate context structure for each module that cannot communicate directly with each other but are dependent on each other in terms of content. In addition, the context updates each component it is connected to on any state update it holds. The components that listen to the context must already need that context. If you find any state you call unnecessary, either that state has no use for the context or you have built the context incorrectly. "

An article about the differences between using redux and context api made me understand the subject better.

I think I will look at the data retrieval from API, context usage, re-rendering again tomorrow morning. Seeing the comment of one of the authors of both redux and react , I had the feeling of reading Alan Key's thoughts while studying OOP.

Day 132

Day 133

Day 134

The meaning and significance of the day for me is that I wrote an answer to a question on Stack Overflow for the first time. It was actually one of those simple questions that was asked in many places but not answered properly (although the answer was given on Github around 2015-16, that was also added). Of course, it may not be right to write about something I have never mastered and just started, but I wanted to write because I thought I understood the cause of the problem encountered. If it is wrong, I will delete or update it, of course, I think there is nothing to be ashamed of.

Day 135

Day 136

@react-navigation/stack

@react-navigation/native-stack

Day 137

Day 138

Day 139

I also did the creation of the user token on the front end side, but then I completed it on the server side. First I took the unique id obtained from the user's phone. Then I used one of the examples in the following answer that I came across while researching how to create a unique id. Although I wonder how the algorithm works, I plan to look at it tomorrow after work. Because I have not yet understood how a unique id can be created with a string expression with a finite number of lengths. In summary, I created a token by combining the unique id received on the user's phone and a unique value I created. Then, when the user contacts the server, he can prove his existence by sending this token in the header. Even if the user deletes the application, since the unique id from his phone can remain with us, his information can be reused and remembered.

Even though I thought you might ask me if I was still looking at it afterwards, I still looked at call-by-value-reference a little bit. This time I found something different. I learned that object is neither pass-by-value nor pass-by-reference. Obviously, although php, javascript and many modern languages use pass by value by default, call(pass)-by-sharing was an evaluation strategy for object.

As I understand it, objects are neither cloned nor copied. Objects are shared. Yes, sharing is mentioned. Let's go with an example (taken from (the first answer ):):

function changeStuff(a, b, c)
{
  a = a * 10;
  b.item = "changed";
  c = {item: "changed"};
}

var num = 10;
var obj1 = {item: "unchanged"};
var obj2 = {item: "unchanged"};

changeStuff(num, obj1, obj2);

console.log(num);  //10
console.log(obj1.item);  //changed
console.log(obj2.item);  //unchanged

Day 140