Heraclitus said that . The reactive paradigm followers like to say that . The phrase attributed to Heraclitus is valid for both functional and reactive paradigms. In the first one, we have pipelines, in the second one – streams. everything flows everything is a stream That testifies to the significant similarity between these paradigms and shows that reactive programming (but more FRP) is, in fact, an asynchronous implementation of a functional flow. There are many studies on the subject of functional programming. However, finding noteworthy resources about naming or specific inspiring conventions is quite a challenge. It requires a healthy dose of creativity and often turns out to be far more complicated than it might seem at first glance. How to standardize descriptive names? — , “Master the JavaScript Interview: What is a Pure Function?” Good programmers give functions descriptive names so that when we see the code, we can see the function names and understand what the function does. Eric Elliott In essence, I’ve observed that many programmers have a problem with descriptive names. The style guide that my colleagues from Straal and I have created is a fulfillment of our experience and expectations, presenting a ready set of good practices and restrictions in our projects. It makes our code reviews much easier and effectively tackles issues such as naming dilemmas. The article that you read is an analysis of our style guide, and you can find it . Besides, we apply strict ESLint rules, which are complementary to this style guide. on our GitHub repository Why “Lexical functional”? “Composition is a powerful tool for abstraction that transforms imperative code into more readable declarative code” — Kyle Simpson, “Functional-Light JavaScript” The declarative composition is essential for understanding what FP is, but we’ll go one step ahead and think about the naming structure in our functions. The inspiration for the title is “ ”, which provides a specific grammar framework to focus on the syntax of multiple dimensions of the linguistic structure. Lexical functional grammar “Functional” is something more than just a common phrase — it’s a connection of both ideas to focus on specific problems for code writing. In this article, you will see the jargon and structures to the naming convention in the FP-inspired world. Sometimes I use specific FP-terms in brackets to provoke your curiosity or wink knowingly at those already familiar with them. Constants only It’s worth pointing out that constants are the strictest declaration. This is the first step in avoiding mutations because using other variable declaration can result in side effects appearing quickly. For boolean values describing a state of something we mostly use the following convention: As you see we have the following scheme for the functions with a specific role (I describe this part in detail in further sections): Why do we use const operators in this case? Because it provides the and helps to take care of a correct order in the code. temporal dead zone Operations and operator functions The above scheme could be a base for most of your problems in a naming dilemma. As you see, our composition includes target collection (also known as a because it is mappable), reducer (an ), and optional argument — in this case “accumulator”. functor operator function Let’s start from “reduce” — the word is a verb which indicates an action, so it is an — a declaration with defined scopes per argument with all the information on what that function does. operation We also have an operator called “reducer” (or “iteratee”) — a noun, which means it’s a role that provides functionality to realize “reduce” operation, we called it an . operator function “Reduced” is an adjective and indicates that something has been completed — it is a result of our process. Let’s check implementations of reduction in and — as you can see, that that terminology is nothing innovative and you have probably seen it before. Now it’s time to use it more consciously and look for analogies in your code. Lodash vanilla JS For a more “lexical” way, we can use it in our code as a suffix — then you always know what the role of each of the individual variables is: In the sort functions (“union”, “sort”), the invoke function per element is called a . For “filter”, “some”, “find”, and similar operations (using probably pure functions) we use predicate function called or just : comparator checker predicate In the next part of the article, you can see we use that convention totally in all cases. Pipelines Pipelines are a handy thing to a flow between functions. It’s an essence of functional programming. Pipe (or compose in the opposite direction) as a functional pipeline: Pipe operator in a reactive stream: Both ways – reactive and functional use the same concept of a pipe. The main difference is, of course, the approach to synchronicity. Curry and partial Forget about “this”, “apply”, and “call” methods. Everything you need is a flat description of flow and proper declarations that express your control flow with the partial transmission of arguments: We have extended the example of reducing called “curriedReduce” (we can also call it “reduction”) — it means that you have to execute that function to end the process. Pay attention to vocabulary — call your curried functions “curriedSomething” or as an ongoing process (like in this case, “reduction”). We can also create curried setters with predefined arguments or change the order of execution and use partial. The result of the implementation of both functions will be the same: For a simple merging, “spread operators” will be enough. For more involved, you should remember about avoiding mutations on your reference, use Lenses, or immutable library like Immutable.js. The analogic situation with getter functions: Avoid if/else Instead of them, you can use conditional (ternary) operators and cond functions. That increases clarity, and helps to avoid imperative chaos in your code. Conditional (ternary) operators — the condition can be a (returns true or false) or (e.g. hasFoo): predicate boolean A better choice for more complicated cases: Objects We have three typical use cases: dictionaries, switches, and factories. Dictionaries We use dictionaries just like in other languages to keep key/values: Switches In most cases, we can replace typical JS Switch (with break/return) by cond operation function. But in this case, any conditional will be executed if none of them comes true. In some extreme situations, getting a specific function by a key value is a better choice. The following code shows behaviour similar to a classical switch. Factories We use neither classes nor constructors. are functions that create objects of any kind— singleton or instances. The term “middleware” is used to define the factory function with partial arguments, e.g., initial options. Our implementation of Factory is quite specific — we don’t use this (to use more explicit contexts and for more FP-friendly style), so you can’t chain methods, but you can use the pipeline: Factories Reactive streams It’s customary to use a “$” suffix in streams. We distinguish two types of observables: hot and cold — everything will be more apparent with the rules below. Hot observables: Hot observables are independent of subscribers — it can emit some changes without an observer. In this case, we use suffix ‘Dispatcher’ because we use them like a singleton — for one event, we have only one declaration on the whole code and reuse it by importing: Cold observables: In any other case, the observable will be cold: Stream creators: For functions that create a new observable: Summary I know that the topic has not been exhausted, yet hope that the analysis of tools and approaches will be helpful and useful for you. I hope that you enjoy the presented proposition of a solution for a common problem of many teams — a naming inconsistency in code. If you have any ideas for improvements, feel free to leave me a comment. If you have seen that you can improve some of this, I’m waiting for your comment, or you can think about your own “lexical guide”. Spread the word! What’s next? For more information about FP I can recommend these lectures: “Functional Light JavaScript” by Kyle Sympson “Composing Software: The Book” by Eric Elliot “Functional Programming Jargon” And, if you are keen on gaining knowledge pertaining to the whole digital world, don't wait and take a closer look at our blog here !

Visit our website!

Too Long; Didn't Read

Make resilience your competitive advantage

What is Lexical Functional Programming ?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

10 Websites to Learn JavaScript for Beginners

104 Stories To Learn About Programming Top Story

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

10 Websites to Learn JavaScript for Beginners

104 Stories To Learn About Programming Top Story

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps