Wpis z mikrobloga

#javascript

Dziubaski używające ES6 mam pytanko: To moje pierwsze podejście z JS i nie za bardzo mam pomysł jak podejść do tematu import / export. Tzn. zasady jakie tym rządzą wiem, wiem jak z tego korzystać teoretycznie.

Tylko w praktyce się gubię, generalnie mam 3 rodzaje modułów:

* moduł który exportuje klasę (konstruktor)
* moduł który exportuje singletona
* moduł który exportuje gołe funkcje

Obecnie rozwiązuje to tak, że w przypadku klasy daje po prostu "export default class XYZ" ;
singletona robię tak, że tworzę klasę singletona a potem eksportuję export default new SingletonClass(); (podoba mi się czytelność funkcji itp w ramach klasy).

Oprócz tego eksportuje jeszcze moduły pomocnicze które mają w sobie zmienne lub funkcje.

I teraz problem w tym, że nie wiem którą drogą iść, w przypadku klasy i singletona to rozwiązanie jest oczywiste. Natomiast w przypadku exportowania gołych funkcji nie wiem czy powinienem zrobić to na zasadzie

export default { funkcja1: () => {..} , funkcja2: () => {..} }

czy na zasadzie "export function funkcja1() .... export function funkcja2()"

i czy importować to na zasadzie:

import Util from 'support/util.js';
const value = Util.clamp( Math.random() , 0.25 , 0.75 );
const test = Util.inRange( value , 0.25 , 0.75 );

czy na zasadzie:

import * as Util from 'support/util.js';
const value = Util.clamp( Math.random() , 0.25 , 0.75 );
const test = Util.inRange( value , 0.25 , 0.75 );

czy na zasadzie:

import { clamp , inRange } from Util;
const value = clamp( Math.random() , 0.25 , 0.75 );
const test = inRange( value , 0.25 , 0.75 );

Obecnie mój codebase oferuje zupełnie różne standardy, raz robię tak, raz tak, a raz jeszcze inaczej :P No i chcę to przerefactorować żeby to było spójne ale nie wiem którą drogą iść, nie mogę się zdecydować.

Dzięki z góry! :)
  • 7
@larvaexotech:

ja tam robie tak jak duze libki robia wiec jak eksportuje wiecej rzeczy to wszystko osobno np

export function fn1(){}
export function fn2(){}

a importuje like so

import { fn1, fn2 } from 'foobar';

przyklad: https://github.com/facebook/immutable-js/blob/master/src/Map.js

niektore libki np loodash robia tez taki myk zeby zredukowac wielkosc twojego bundle.js dla frontu

import fn1 from 'foobar/f1';

@@ edit: w sensie z tym lodashem to mi chodzi o to, ze jak to
@taximan: Masz racje ciekawy punkt widzenia. Z tego co wiem WebPack (a go uzywam) eliminuje deadcode przy produkcyjnych buildach.

Z drugiej strony patrząc na czytelność kodu, to np. ja wolę żeby to było (przykładowo lodash)

costam = _.map( ... )

niż

costam = map( ... )

Bo wtedy robi się lekki zamęt mając funkcje "tak jakby globalne", wiesz o co mi chodzi.
@larvaexotech:

No nie wiem czy webpack eliminuje dead code paczek ktore bierzesz z npm bo gdyby tak bylo to zobacz na np ten modul https://www.npmjs.com/package/history stworzony przez ludzi od react routera, ktorzy sa swiadomi webpacka, raczej by nie robili takich imo hackow jak tutaj.

https://github.com/rackt/history/blob/master/docs/GettingStarted.md

sekcja: Minimizing Your Build.

Tylko by raczej odrazu napisali aby zastosowac webpackowego optimizera i sie niczym nie martwic. Chociaz tbh nie mam pojecia, nigdy mi sie
@taximan: Słuchaj a czy przyjęcie konwencji takiej, że nazwę importowanego modułu zaczynam z dużej litery to dobry pomysł?

Bo nie chcę jakoś rażąco odchodzić od standardów JSowych i ES6, ale strasznie mnie #!$%@? że np. mam moduł /service/auth/user.js <-- który zarządza użytkownikami po stronie backendu, wiesz rejestracja i inne bzdury. I chodzi o to że jak go zaimportuję:

import user from '/service/auth/user.js';

to potem nazwa user mi sie #!$%@? bo już
@larvaexotech:

Duze litery z poczatku nazwy sa zarezerowane dla konstruktorow, wiec poki nie mozesz zrobic czegos typu:

var user = new User();

to radze nie eksperymentowac bo jest to bardzo powszechna konwencja.

Mi tam nazwy nigdy nie konfliktowaly na tyle aby to byl wiekszy problem, wiec nie mam zbytnio innych rad dla ciebie, moze tylko taka zeby sie wyposazyc w ogarnietego IDE / edytora tekstowego. Ja korzystam glownie z Visual Studio