You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: COMPARE.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
# Comparison with other libraries
2
2
3
3
## [Ramda](http://ramdajs.com/)
4
-
Ramda was a massive influence on Tinkoff Utils It borrowed the same functional programming approach, naming, and many other things. However, Tinkoff Utils doesn't provide placeholders, lenses and some other less popular stuff.
4
+
Ramda was a huge inspiration for Tinkoff Utils! it has a lot of similarities with naming style, uses same functional programming approachand many other things, with lack of some less popular design ideas like `__` prefixes, lenses and etc
5
5
6
6
| Ramda | Utils |
7
7
| --- | ------ |
@@ -114,8 +114,8 @@ Ramda was a massive influence on Tinkoff Utils It borrowed the same functional p
114
114
115
115
116
116
## [Lodash](https://lodash.com/)
117
-
Be careful when migrating from lodash to Utils:
118
-
1.Check function signature, since Utils uses data as the last argument in contrast with lodash
117
+
When migrating from lodash to Utils, keep in mind that –
118
+
1.Lodash has different function signatures, since Utils uses data as the last argument in contrast with lodash
119
119
1. Singular lodash methods can accept various argument types when Utils functions are focused and cohesive
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+22-20Lines changed: 22 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,31 +1,34 @@
1
1
# Contributing
2
-
1. Fork this repository.
3
-
1. Install dependencies with `npm install`.
4
-
1. Make sure tests are passing running `npm run test`.
5
-
1. Make your changes. Make sure the commands `npm run build` and `npm run test` are not failing.
6
-
1. Finally send a GitHub Pull Request with a clear list of what you've done (read more [about pull requests](https://help.github.com/articles/about-pull-requests/)). Make sure all of your commits are atomic (one feature per commit).
2
+
1. Fork this repository
3
+
1. Create a future branch (don't make changes in master branch)
4
+
1. Install dependencies with `npm install`
5
+
1. Make sure tests are passing by running `npm test`
6
+
1. Make your changes. Make sure `npm run build` and `npm test` will not fail
7
+
1. Send us pull request with a clear list of what you've done (read more [about pull requests](https://help.github.com/articles/about-pull-requests/)). Make sure all of your commits are atomic (one feature per commit) and have tests
7
8
8
9
## How to add new utility
9
-
1.Decide where to place new utility according to the structure of the library.
10
-
1.Pick the name of the new utility (corresponding to the functionality or well-known name if there is analog in other libraries (ramda, lodash))
11
-
1. Create a new file with picked named in the corresponding directory, and add a file with the same name to the '_\_tests__' directory.
12
-
1. Implement new functionality. For autocurrying wrap utility to `/function/curry` or `/function/curryN` (`curry` doesn't support default and rest arguments, so prefer `curryN`).
13
-
1. Add tests (don't forget edge cases and exceptions).
14
-
1. Add JSDoc with the description of functionality, arguments types and a little example.
10
+
1.Pick the descriptive name for the new utility
11
+
1.Decide where to place it
12
+
1. Create a new file with the same name at the proper path, and add a file with the same name to the `__tests__` directory
13
+
1. Implement new functionality
14
+
1. Add tests (don't forget edge cases and exceptions)
15
+
1. Add JSDoc with the description of functionality, arguments types and a small example
15
16
16
-
## How to write JSDoc right
17
-
List of supported tags is [here](https://esdoc.org/manual/tags.html).
17
+
**Protip**: For autocurrying wrap utility to `/function/curry` or `/function/curryN` (`curry` doesn't support default and rest arguments, so for the most cases use `curryN`)
18
+
19
+
## How to write JSDoc
20
+
First, check out [documentation](https://esdoc.org/manual/tags.html) for all supported tags.
18
21
19
22
JSDoc should contain the following:
20
-
1.The description of a utility.
21
-
1.Add arguments types and description for them (see @param).
22
-
1. Add the type and the description of the return value (see @return).
23
-
1. Add an example to demonstrate the usage of a utility (see @example).
23
+
1.Description of a utility
24
+
1.Arguments types and description for them (see [`@param`](http://usejsdoc.org/tags-param.html))
25
+
1. Add type and description for the return value (see [`@return`](http://usejsdoc.org/tags-returns.html))
26
+
1. Add an example to demonstrate the usage of a utility (see [`@example`](http://usejsdoc.org/tags-example.html))
24
27
25
-
If there is some additional information you want to add, prepend it with `**Note:**`.
28
+
If there is some additional information you want to add, prepend it with `**Note:**`
26
29
27
30
### Example
28
-
```javascript
31
+
```js
29
32
importcurryNfrom'../function/curryN';
30
33
31
34
/**
@@ -37,7 +40,6 @@ import curryN from '../function/curryN';
37
40
* @return{Boolean} `true` if the predicate is satisfied by at least one element, `false`
0 commit comments