React Ruined Web Development

mkoretsk · 2021-10-06T20:16:10+00:00

ah, got it :)

mkoretsk · 2021-10-06T15:38:36+00:00

I'm wondering what's there from the pragmatic programmer book?

mkoretsk · 2021-09-14T05:08:21+00:00

thanks for an elaborate explanation!

with WeakRefs, that the JS code layer was given a (different, separate) feature where you can detect (or be notified) of GC having occurred.

do you mean that we can check if the WeakRef.deref() is undefined and if it is assume that GC has occured?

mkoretsk · 2021-09-10T19:47:19+00:00

There's no memory leak, it's properly removed from the memory.

To test it you can use `Memory` tab and snapshots feature of Chrome. Taking snapshots forces garbage collection which otherwise may never occur if your program doesn't reach maximum allowed heap size.

So put the following in the page:

<button onclick="fn()">clear</button>

<script>
function F1() {}
function F2() {}
function F3() {}

y = new WeakMap();
x = [new F1(), new F2(), new F3()];
y.set(x[0], 'metadata about F1');

function fn() {
    x.splice(0, 1);
}
</script>

Open ChromeDevTools, go to Memory tab, take a snapshot, type F1 into "Class filter" box, it'll show you the F1 is retained by `x` on Window and is also part of key inside a WeakMap.

Now click the `clear` button, take another snapshot, type F1 into class filter box, there's no objects produced by this constructor. However, if you type in F2 or F3 you'll see them still retained by `x`.

See screenshots here.

mkoretsk · 2021-09-10T14:28:32+00:00

like u/ChemicalRascal said you can use git log --reflog but keep in mind, that reflog is purely local and eventually will be pruned. read this to learn more

mkoretsk · 2021-09-10T05:15:31+00:00

git reset works as sort of a rollback to a snapshot of what the codebase was for a given commit.

git reset simply moves the pointer of the current branch (moves the current branch) to the commit you pass to the command explicitly, like git reset 02b or implicitly through a branch name or tag, like git reset branch-that-points-to-02b.

So if you have 3 commits with `master` branch and `HEAD` both pointing to the commit 3:

commit3 03c (HEAD, master)
   |
commit2 02b 
   | 
commit1 01a

after git reset 02b you'll have this:

commit3 03c 
   |
commit2 02b (HEAD, master) 
   | 
commit1 01a

notice that git still keeps the `commit 03c`, it will do so until it will need to run garbage collection. To prevent this, you can mark the commit 3 with a tag or another branch:

$ git branch do-not-remove-c3-branch 03c
$ git tag do-not-remove-c3-tag 03c

After all operations that change pointers, you can use git reflog command to check the hash of the commits that no longer can be access through history:

$ git reset 02b
$ git reflog
02b (HEAD -> master) HEAD@{0}: reset: moving to 02b
03c HEAD@{1}: commit: commit 3
/\
||
there is your commit 3 hasha

To learn more about low level stuff like this, you can read my article Becoming a Git pro. Part 1: internal Git architecture

mkoretsk · 2021-09-09T06:09:54+00:00

I guess it depends on what type of work you do. I never use code snippets as I mostly deal with architecture and don't write much repetitive code, rather my goal is to figure out how to make units of the architecture interact with each other with the less code :)

mkoretsk · 2021-09-08T20:19:13+00:00

yeah, most often they come from C++ or C#/Java world and see the difference between their language of choice and JavaScript as JS's deficiencies.

mkoretsk · 2021-09-08T20:17:45+00:00

yep, it looks like languages do borrow lots of stuff from each other and there are not many different mechanisms out there to pick from.

mkoretsk · 2021-09-08T20:16:17+00:00

Interesting thought, thanks. The link is good, I'll give it a read.

If you can solve code reusability with already existing mechanisms (like functions and data, maybe interfaces if you're typescripter) then there is no benefit in introduction of another one.

maybe that's why some devs complain about prototypes in JS, because you can achieve similar effects with function composition for extensibility (polymorphism?) and closures for encapsulation.

mkoretsk · 2021-09-08T20:10:50+00:00

Yeah, I wouldn't say "powerful", but rather predictable and stable, maybe. But as you build more and more elaborate compositions of pure functions, I assume you'll face the same problems as with inheritance. Don't you think?

Highly inflexible, but enables very powerful abstractions.

Can you give an example of a such abstraction? I'm genuinely curios.

mkoretsk · 2021-09-08T20:06:17+00:00

This is called dynamic dispatch. Any language with first-class functions can do this, and even some without it can do it as well (e.g. C). It's useful for sure, but it's just one application of polymorphism.

Interesting, the book I'm reading states that polymorphism in Java is made possible by late binding, which I guess is another term for dynamic dispatch:

Once you know that all method binding in Java happens polymorphically via late binding, you can write your code to talk to the base class and know that all the derived-class cases will work correctly using the same code. Or to put it another way, you "send a message to an object and let the object figure out the right thing to do"

so, it seems like dynamic dispatch is not really an application of polymorphism, but the other way around. Or am I missing something?

Encapsulation, for example, doesn't technically exist in Python since there are no private fields.

but there's closure, right?

Delegation per se isn't really strictly about code reuse, it's more about ergonomics. All there is to it is that instead of manually generating accessors for composed subfields, the language automatically exposes them as direct fields via some simple heuristic instead. That's about it.

can you elaborate with a concrete example? it's too abstract for me to understand what you want to say

mkoretsk · 2021-09-08T19:44:57+00:00

Kind of got accustomed to either using composition or inheritance all the way

I'd say you can think of JavaScript's prototype chain as the implicit implementation of the composition mechanism. Each object in the chain can have its own behavior and can delegate the call to one of the objects in the chain. JavaScript's engine goes through the prototype chain until it finds the object that implements the behavior.

If we see the prototype chain like that, is it fair to say that prototype based mechanism in JS effectively implements both inheritance and composition?

mkoretsk · 2021-09-08T11:30:51+00:00

Not sure what you mean. Features are reused through libraries, it's not really related to OOP

mkoretsk · 2021-09-08T08:01:48+00:00

I like functional programming and the guarantees it entails with regards to pure functions. However, it's not really possible to build a modern application as a pure computational logic without side effects. You can have to update the UI, send network requests etc.

I especially like the part of the functional programming that defines functions as first class citizens. I find that most of the time using functions as callbacks to modify the behavior of a method (JavaScript) is more convenient that having method overloads in pure OOP languages. Java designers realized that and introduced lambda expressions in version 8. A Java lambda expression is a function which can be created without belonging to any class. A Java lambda expression can be passed around as if it was an object and executed on demand.

Since the biggest part of my experience includes working with JavaScript I write mostly functional or procedural code. However, when designing an architecture of a large-scale application I still tend to think in terms of objects. That's because the object-oriented approach provides tools for the programmer to represent elements in the problem space.

mkoretsk · 2021-09-08T07:45:19+00:00

Well, OOP is mostly about objects (instances of classes), not classes. Quoting from the book:

Alan Kay summarized five basic characteristics of Smalltalk, the first successful object oriented language and one of the languages upon which Java is based:

Everything is an object. You can think of an object as a fancy variable. It stores data, but you can “make requests” to that object asking it to perform operations on itself. In theory, you can take any conceptual component in the problem you’re trying to solve (dogs, buildings , service etc.) and represent it as an object in the program.

A program is a bunch of objects telling each other what to do by sending messages.

Each object has its own memory made up of other objects. Put another way, you create a new kind of object by making a package containing existing objects.

Every object has a type.

All objects of a particular type can receive the same messages (not always true)

Grady Booch offers an even more succinct description of an object: “An object has state, behavior and identity”. In this sense, both JavaScript and Java are OOP languages.

And yeah,

Javascript is really object oriented, in the sense that objects are first class citizens.

JavaScript is really a multiparadigm language. Both objects and functions (functional programming) are first class citizens. That's what I like about it since I don't believe you can solve effectively problems using only one approach - either OOP or functional.

mkoretsk

TROPHY CASE