From 144f08ccaf61960f70582eb24f855dde8031d7b4 Mon Sep 17 00:00:00 2001 From: Dwight Smith Date: Thu, 4 May 2023 16:03:02 -0400 Subject: [PATCH] Update README Refactor grammar in readme file --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 1a68c2c..8914d58 100644 --- a/README.md +++ b/README.md @@ -83,7 +83,7 @@ const text = [Full article on bridge pattern](doc/bridge-pattern.md) Now let us consider a pattern very useful in front-end projects. A component -that seems very simple to implement but usually turns the opposite is the +that seems very simple to implement but usually turns out the opposite is the button component. It starts with some border radius and primary and secondary color palette. However in the life-time of the project several features are requested that make this component bloated or split in two with not obvious @@ -151,7 +151,7 @@ based on different data. In the *builder pattern* the construction of an object, or even a composite, is done in multiple steps, for example while chunks of data arrive. It should -the `toElement` function to return the final element. +call the `toElement` function to return the final element. ``` @@ -171,8 +171,8 @@ class Builder { [Full article on mediator pattern](doc/mediator-pattern.md) -The *mediator pattern* allows two or more object to communicate without any of -this object depending on the other. This pattern is rarely seen in React +The *mediator pattern* allows two or more objects to communicate without any of +the objects depending on the other. This pattern is rarely seen in React programming because the communication is usually handled by third-party libraries or state containers, most notably *Redux*. This is not exactly right for two simple reasons: