Argument z funkcji jako własność tablicy

Question

Mam listę użytkowników i chcę zrobić funkcję, która będzie logować użytkownika jeżeli znajdzie odpowiadającą mu wartość własności.

const userList2 = [
    user1 = {
        login: 'user1',
        email: 'user1@wp.pl',
        password: 'password1',
        address: 'owocowa1',
        profilePhotoLink: 'https://link1.com'
    },
    user2 = {
        login: 'user2',
        email: 'user2@wp.pl',
        password: 'password2',
        address: 'owocowa2',
        profilePhotoLink: 'https://link2.com'
    }
]

i metoda

const findByProperty = (prop, value) => {
    for (const user in userList2) {
        if (userList2.hasOwnProperty(user)) {
            for (const val in userList2[user]) {
                if (Object.prototype.hasOwnProperty.call(userList2[user], val) && userList2[user].prop === value) {
                    console.log(userList2[user])
                    break;
                }
            }
        }
    }
}

Czyli jako prop podaję na przykład email, a value to na przykład user2@wp.pl

I pojawia się problem w tej linijce 

if (Object.prototype.hasOwnProperty.call(userList2[user], val) && userList2[user].prop === value)

Mianowicie, jak przypisać(?) ten prop to userList2[user]? Próbowałem arguments[0], ale też nie działa, z ${prop} to samo. Nie chcę robić osobnej metody dla każdej z możliwych properties.

Comments

strasznie masz zamotaną tą funkcję... rozumiem, że biznesowo przychodzi Ci do funkcji X lista z następującym interfejsem:

interface User {
        login: string,
        email: string,
        password: string,
        address: string,
        profilePhotoLink: string
    }

i teraz mamy listę:
const users: User[] = ...

jeśli tak, to napisz biznesowo co chcesz dokładnie uzyskać i dopiero wtedy wejdziemy w implementację, najpierw poznajmy założenia biznesowe problemu.

---

Tak, do funkcji przychodzi mi cała lista.

W funkcji chcę przeszukiwać tę listę użytkowników po wybranym property i wartości tego property i końcowo zwrócić użytkownika bądź listę użytkowników, którego/ których wartości property zgadzają się z podanym jako argument.

przykładowy wynik z przykładu podanego w pytaniu: 

{
        login: 'user2',
        email: 'user2@wp.pl',
        password: 'password2',
        address: 'owocowa2',
        profilePhotoLink: 'https://link2.com'
 }

 

---

1. użytkownicy są w tablicy, więc użyj array methods w tej serii na yt masz pięknie opowiedziane o wszystkich, to mocno ułatwia pracę i sprawia, ze Twój kod jest czytelniejszy.
2. jeśli dobrze rozumiem to funkcja ma wyjmować z tablicy użytkowników, którzy mają wartość X w property Y. X i Y mają być podane w argumentach funkcji. tak?

---

tak, dokładnie

---

a nie lepiej zrobić to funkcją skrojoną konkretnie pod ten typ obiektów? Nie jestem zwolennikiem robienia maksymalnie uniwersalnych rozwiazan, są one trudne w utrzymaniu i analizie. Oczywiście co innego jak np. robimy jakąś libkę itp, ale wewnętrznie w apce raczej preferuję konkretne funkcje, np. chcemy userów, którzy mają konkretną wartość pola email, czyli robimy:

function getUsersWithDefinedEmail(users, email) {
  return users.filter(user => user.email === email);
}

takie coś znacznie łatwiej się czyta, od razu wiesz co i jak. Pytanie dlaczego chcesz zrobić rozwiązanie maksymalnie uniwersalne, zamiast takiego prostego?

---

okej, w takim razie postawię na takie rozwiązanie :)
chciałem zrobić uniwersalne rozwiązanie, żeby trochę zaoszczędzić na kodzie, bo wiadomo, że w razie gdybym powiększył userów o kolejne property, to znowu muszę pisać kolejną metodę
dziękuję za poświęcony czas

---

ja podchodzę do takich problemów tak - jeśli obecnie jest to tylko jedno property to lepiej zrobić konkretną metodę, jasno nawet swoją nazwą wskazującą co i jak.

Jeśli doszło by drugie/trzecie property to można by zrobić np. jakiś builder, który wykorzystywałby trzy pojedyncze metody sprawdzające konkretne property (i swoimi nazwami mówiące co analizujemy).

Jeśli miałbyś mieć tego jeszcze więcej to najpierw, zamiast robić mocno uniwersalną funkcję zastanowiłbym się, czy na pewno dobrze podchodzimy do całego problemu... czy może takie filtrowania, walidacje itp. nie powinny być rozrzucone na inne poziomy itp.

Jeśli ostatni punkt nadal wskazuje na rozwiązanie o jakim tu mówimy w tym wątku to dopiero to jest miejsce na stworzenie tak uniwersalnej metody.

Ewentualnie, gdybyś potrzebował np. reużyć ten sam mechanizm filtrowania/walidacji itp. na róznych zbiorach danych... ale wtedy podszedłbym do tego inaczej:

// jakiś uniwersalny util:
getFilteredItems(items, conditions) {}

// w miejscu filtrowania userow:
getUsersWithDiscounts(users) {
  return getFilteredItems(users, jakies-warunki-rabatowe);
}

czyli opakowałbym wywołanie uniwersalnego utilsa w dodatkową funkcję/metodę której nazwa jasno wskaże co chcemy zrobić.

Także jak widzisz nie ma uniwersalnej odpowiedzi na Twoje pytanie, wszystko zależy od przypadku :) ale generalnie nei staraj się na siłę robić super uniwersalnych rozwiązań jeśli aplikacja tego nie wymaga. Lepiej zrobić w razie czego refactoring niż od razu iść w mega uniwersalizm, optymalizacje itp.

I taka uwaga na koniec - po napisaniu jakiegoś kodu zastanów się, na ile jest on wg Ciebie czytelny dla nowej osoby, która wchodzi dopiero w dany projekt i nie zna dobrze domeny, wszystkich założeń biznesowych itp. Czy jest w stanie się w miarę w nim ogarnąć.