Javascript pure function import strategy - javascript

I have a class file, utility.js for all the common functions.
However some of the functions require certain library import
e.g: NetInfo library
utility.js
import NetInfo from "#react-native-community/netinfo";
export async function networkConnection() {
const state = await NetInfo.fetch();
return state.type;
}
However, in order for utility.js to be reusable in another project, another project has to have NetInfo installed. Is it a good practice if instead of importing modules directly, I import only when I need to use it, and pass the import object along to the function?
utility.js
export async function networkConnection({ NetInfo }) {
const state = await NetInfo.fetch();
return state.type;
}
and when using it
app.js
import NetInfo from "#react-native-community/netinfo";
import { networkConnection } from "./utility.js"
const network = networkConnection({ NetInfo })
This way, I can copy and paste utility.js to any project, without the need to install all the import packages. Also, this pattern seems to be able to resolve common Circular Dependencies error by limiting the import statement.
Is this the best practice for creating a common, reusable function file?

Your question illustrates the difference between a closure and a plain function, however, neither are pure.
If the function only serves to await a promise and return a property value, it doesn't really make sense to use the non-closure approach... unless you've created a module (utility.js in your example) with other exports unrelated to the NetInfo context. If that's the case, I think that's the issue to focus on: reorganization of your code's concerns.
How many characters it takes to get the value two ways:
console.log(`await networkConnection()`.length); // 25
console.log(`(await NetInfo.fetch()).type`.length); // 28
Is it worth the abstraction? Up to your brain and your fingers.

Related

How are the imports implemented in different React libraries and how can I implement the same pattern in my own library?

For example, the recommended way of importing in React Bootstrap is to go this way:
import Button from 'react-bootstrap/Button' instead of import { Button } from 'react-bootstrap';
The reason is "Doing so pulls in only the specific components that you use, which can significantly reduce the amount of code you end up sending to the client."
source: https://react-bootstrap.github.io/getting-started/introduction/
Same for React MUI components:
import Button from '#mui/material/Button';
source: https://mui.com/material-ui/getting-started/usage/
I want to implement something similar in my React components library, to limit the usage of code in the bundle, but I don't know how they implement this specific pattern. I have looked at their code base, but I don't quite understand.
Basically it is all about modules and module files and their organization. You can have a lot of.. lets call them folders, "compoments/*" for example. "components/button", "components/alert", "component/badge", and other things. All of them will have some index.js or .ts file that will export or declare and export all the functionality that needed in order to make this component work, 'react-bootstrap/Button' for example. Ideally all those subfolders or submodules are independend from each other, no references between them but probably each one will have 1 reference to 1 common/shared submodule like "components/common" which will contain some constants, for example, and no references to other files. At the top level of them you will have another index.js or .ts file that is referencing all of those components, so "components/index.js" will import and reexport all the nested components index files. So in order to import a Button, for example, you can either import "components/index.js" file with all the other imports this file is using, either only 1 single "components/button/index.js" file which is obviously much more easy to fetch. Just imagine a tree data structure, you import root of the tree (root index.js) - you get all the tree nodes. You import one specific Node (components/button/index.js) of the tree - just load all the childs (imports) of that node.
Sorry for a long read but asuming you mentioned webpack - there is a technique called tree-shaking which will cut off all the unused things.
Info about modules: https://www.w3schools.com/js/js_modules.asp
Info about Tree-Shaking: https://webpack.js.org/guides/tree-shaking/
It might not be as complicated as you think. Let's say you write the following library:
// your-library.js
const A = 22
const B = 33
export function getA () { return A }
export function getB () { return B }
export function APlusB () { return A + B }
// a lot of other stuff here
If some consumer of your library wants to make use of the APlusB function, they must do the following:
// their-website.js
import { APlusB } from 'your-library'
const C = APlusB()
However, depending on how the code is bundled, they may or may not wind up with the entire your-library file in their web bundle. Modern bundling tools like Webpack may provide tree shaking to eliminate dead code, but this should be considered an additional optimization that the API consumer can opt into rather than a core behavior of the import spec.
To make your library more flexible, you can split up independent functions or chunks of functionality into their own files while still providing a full bundle for users who prefer that option. For example:
// your-library/constants.js
export const A = 22
export const B = 33
// your-library/aplusb.js
import { A, B } from 'constants'
export default function APlusB () { return A + B }
// your-library/index.js
// instead of declaring everything in one file, export it from each module
export * from 'constants'
export { default as APlusB } from 'aplusb'
// more exports here
For distribution purposes you can package your library like so:
your-library
|__aplusb.js
|__constants.js
|__index.js
You mentioned react-bootstrap and you can see this exact pattern in their file structure:
https://github.com/react-bootstrap/react-bootstrap/tree/master/src
and you can see they aggregate and re-export modules in their index file here:
https://github.com/react-bootstrap/react-bootstrap/blob/master/src/index.tsx
Essentially, what you are asking is:
"How to export react components"
OR
"How are react components exported to be able to use it in a different react project ?"
Now coming to your actual question:
import Button from 'react-bootstrap/Button' instead of import { Button } from 'react-bootstrap';
The reason is 'Button' component is the default export of that file react-bootstrap/Button.tsx. So there is no need for destructuring a specific component.
If you export multiple components/ functions out of a file, only 1 of them can be a default export.
If you have only 1 export in a file you can make it the default export.
Consider the file project/elements.js
export default function Button(){
// Implementation of custom button component
}
export function Link(){
// Implementation of custom Link component
}
function Image(){
// Implementation of custom Image component
}
Notice that the Button component has 'default' as a keyword and the Link component doesn't.
The Image component can't even be imported and can only be used by other functions/components in the same file.
Now in project/index.js
import 'Button', {Link} from './elements.js'
As Button component is the default export its possible to import without destructuring and as Link component is a regular export, I have to destructure it for importing.

Export a Monkey Patch library and Import it into a separate file in Javascript

I'm working in WebDriverIO w/Mocha, and there's some monkey patches I've written to make my code easier to read. Things like:
Object.prototype.findEntries(...arr) for getting a subset of Object.entries(),
String.prototype.padding(int), adding spacing to the right of a string,
Array.prototype.sortByKey(key) to sort an array of similar objects by the value of a common key, and
Array.prototype.last(), the classic.
Since I have many spec files with even more tests, I'd like to have a MonkeyPatchLib.js in my project that I can import into my spec files, so I can call these custom functions when needed:
myTest.js:
import { all } from './MonkeyPatchLib.js' // <- line in question
describe('My First Spec File', async() => {
it('First Test', async() => {
let myArr=[1,2,3]
console.log(myArr.last())
})
})
I've screwed around with module.exports=[func1(){...},func2(){...}] to no avail. I'm aware that I can simply create custom classes (a la the solution to this question) and export those, but that would require an annoying refactor of my codebase. How should I format the library, and how would one import said library?

Memory when importing js objects in react

I am new to react and its transpiled way of generating javascript.
In react side, I have a class Utility that uses a data object UserData organized as below -
UserDataObj.js
class UserData{
this.someobj = {};
//some function here
something(){
}
}
const UserDataObj = new UserData();
export {UserDataObj};
Utility.js
import {UserDataObj} from './data/UserDataObj';
class Utility {
doSomething(){
//UserDataObj.something();
}
}
const utility = new Utility();
export {utility};
I have another ReactApp UserApp.js, that also uses UserDataObj and Utility (although not good design wise) -
import {UserDataObj} from './data/UserDataObj';
import {utility} from './Utility';
class UserApp extends React.Component{
//does something with UserDataObj
// also does somethign with utility
}
My question is, how many utility and UserDataObj instances will be created in memory, when UserApp is rendered. My guess is, it should be only 1 instance for both. But I want to confirm if importing n times creates a new instance every time.
Any good read on this topic is greatly appreciated.
Thanks
This depends on the bundling tool, and not React. I imagine that the new browser ES Module resolution scheme works in the same way.
Most bundlers that I know of, and other import schemes such as Node.js' require module resolution will cache the import between files and always return the same exported objetcs. This is a requirement for prototype inheritance, for example, otherwise, it would mess up the instanceof operator.
That exported new Utility() instance will be the same for any module that imports it. In order to generate new instances, you would have to have a function.

Is it possible to use Node.JS based module from Java?

I was working on a React Native Native Module for Android. And it is written in Java (as what I researched from official docs and the internet). The problem is, I need to use a Node.JS based module to implement the functions that I want. Is there any possibility to use Node.JS module in Java?
The Node.JS module currently using a few Node native libraries such as fs and path. The code is 100% written using Node.JS.
Or is there any other way to create a React Native module without the use of Java?
The ultimate goal is to use this Node.JS based module to React Native App (without create a bridge between Node and React Native).
As I understand your question, your module doesn't have to communicate with native side. If it's that what you need, it will so easy to achieve. I'll make a simple example:
yourModule.js
export function a() {
// do sth
}
export function b() {
// do sth
}
export function c() {
// do sth
}
yourComponent.js
There is 2 ways to use your module:
1.
import { a, b } from '/path/yourModule'; // if you want to import some of the functions
class yourComponent {
function test() {
a(); // call function a from module
}
}
// Remember to check function's name if it's duplicated with other modules
2.
import * as module1 from '/path/yourModule';
class yourComponent {
function test() {
module1.a(); // call function a from module
}
}
// In this case, you won't have to worry about duplicated function's name, but you still
// have to check duplicated of the name of modules you have imported. For this example,
// the name module1 has been used.
P/s: you might get some error when using export/import incorrectly. So please investigate more about React Native export/import.

Document function that returns object property by parameter

I'm making an Api repository for my Vue.js application, following this article.
Thing is, I like to document my functions so I have better code completion on VSCode. I typically use jsDoc for this.
I'm stuck here:
import DiarioEscolarRepository from './diarioEscolarRepository';
import PeriodoAvaliativoRepository from './periodoAvaliativoRepository';
import AtividadeAvaliativaRepository from './atividadeAvaliativaRepository';
import CorteEtarioRepository from './corteEtarioRepository';
const repositories = {
diarioEscolar: DiarioEscolarRepository,
periodoAvaliativo: PeriodoAvaliativoRepository,
atividadeAvaliativa: AtividadeAvaliativaRepository,
corteEtario: CorteEtarioRepository,
};
export default const RepositoryFactory = {
get(name){
return repositories[name];
}
};
I need to make it so the editor understands that the get function is a simple acessor to the repositories object.
I tried using #typedef and #type, but none of them worked properly.
I tried something like #returns {repositories.name}, but is also does not work.
Is there a way to document this?
I also thought about using a typescript definition file but I never did it, so I don't know where to begin.

Categories