Dodawanie wlasnych prototypow do typow prostych.

Czesc pisze sobie apke w ReactJS i pisze do komponentu ktory najprawdopodobniej bedzie przenoszony z projektu do projektu proptypes. O ile wbudowane protypy sa dosc rozbudowane to jednak musze napisac wlasna funkcje, sama funkcja to banal, ale chcialbym sie dowiedziec czy napisanie takiego kodu nie jest po prostu bledem, poniewaz tworze nowe prototype do typu prostego (boolean) i wydaje mi sie to zle, ale zapytam bardziej doswiadczonych. Oto kod:

 
	Boolean.prototype.throwErr = function(msg) {
		if (!this) return new Error(msg);

		return null;
	}
	function keysNumbersPropTypes(errMsg){
		return (props,propName) => Object.keys(props[propName]).every( x => parseInt(x) ).throwErr(errMsg);
	}
	Component.propTypes = { 
     	  data:keysNumbersPropTypes('Key in data must be number!'),
	};

Wyglada to krotko i zwiezle ale dodaje prototyp do boolean i to mi sie nie podoba.. Wczesniejsza wersja wyglada tak:

 
	function keysNumbersPropTypes(errMsg) {

		return (props,propName) => {
			const keysAreNumbers = Object.keys(props[propName])
		  	.every( x => parseInt(x) );

		  	if (!keysAreNumbers) return new Error(errMsg);
		}
	}
       Component.propTypes = { 
     	  data:keysNumbersPropTypes('Key in data must be number!'),
	};

Nie powinieneś modyfikować prototypów typów wbudowanych.

Na poparcie tego stwierdzenia przedstawię Ci prosty przykład. Pracuję przy projekcie, w którym używana jest biblioteka prototypejs. Z tego co mi powiedzieli koledzy, to taki zły brat bliźniak jQuery. Biblioteka ta modyfikuje prototypy typów wbudowanych przez co jest moim koszmarem.

Jakiś czas temu miałem problem z JSON.stringify/parse - nie pamiętam z którym - chodziło o podwójne cudzysłowy. Biblioteka zmodyfikowała działanie wbudowanej w funkcji, przez co zmarnowałem full czasu.

Ostatnio chciałem użyć zwykłej funkcji z Array.prototype, chyba filter i okazało się, że również jest ona zmodyfikowana w taki sposób, że jej działanie różni się od obecnego standardu (chyba wtedy tej funkcji nie było nawet). Oczywiście za dużo kodu na tym działaniu polegało, więc poza straconym czasem musiałem dodać ekstra kod.

Tak jak Desu pisze, swoją drogą co niby wg Ciebie robi Boolean.prototype.throwErr? Bo na moje oko zwraca zawsze null.

Zwraca error jesli boolean jest false. Tak jak reactowy proptypes tego wymaga. Tak jak myślałem ale chciałem to jakoś skrócić ale to jest źle skrócenie w takim razie wracam do wersji nr.2 . Mam jeszcze pytanie w jeśli chodzi o dodawanie prototypów do kolekcj set lub map? Bo te kolekcje sa dosc ubogie.

Jak zawsze zwraca null skoro to testowalem..

Dodam jeszcze, że ta Twoja walidacja jest strasznie kulawa:

const areKeysNumbers = obj => Object.keys(obj)
  .every(key => parseInt(key));

// Basic tests:

test('Allows simple integers', () => {
  const input = {
    '0': 'foo',
    '1': 'bar',
  };
  const actual = areKeysNumbers(input);
  const expected = true;

  return actual === expected
}); // Ooops...

test('Does not allow strings with number only at the beginning', () => {
  const input = {
    '0x1dupa': 'bar',
  };
  const actual = areKeysNumbers(input);
  const expected = false;

  return actual === expected
}); // Ooops...


function test(description, comparisionFunction) {
  comparisionFunction()
    ? console.log(`%c ✓ Test: ${description}`, 'color: green')
    : console.log(`%c ✗ Test: ${description}`, 'color: red');
}

Maciek, o to właśnie chodzi żeby klucz mógł być '123' ale nie może być '12a'.