Hirdetés

Keresés

Új hozzászólás Aktív témák

  • martonx
    veterán

    Köszi, ez így nekem is szimpatikusabb. Alapvetően én szeretem a destructure-t, de itt valóban sok értelme nem volt, csak az én megoldásommal, anélkül már kész kód tömböt hánytam össze, amin a TS-se segített.

    Hja, a TS-t se szeretem :D

  • inf3rno
    nagyúr

    Működni működik, csak nem tudom, hogy nem csinálok-e felesleges loopokat. [link]

    Átírtam sima JS-re, nem tudom pontosan, hogy hogy működik a jsfiddle TS/Babel.

    @inf3rno: :K Optional Chaning (?.) MDN

    Köszi!

  • martonx
    veterán

    Működni működik, csak nem tudom, hogy nem csinálok-e felesleges loopokat. [link]

    Átírtam sima JS-re, nem tudom pontosan, hogy hogy működik a jsfiddle TS/Babel.

    @inf3rno: :K Optional Chaning (?.) MDN

    Így már világos, hogy mi volt a szándék. Szerintem így sokkal egyszerűbb.
    Ez a kényszeres dekonstruktorozás, amit csináltál, szerintem bőven rontja az olvashatóságot, de persze ez szubjektív.

    [link]

  • inf3rno
    nagyúr

    Előre is elnézést az auto-correctes felig ékezetes, felig magyar, felig angol kommentert.

    Mivel magamtol nem jöttem ra ezért osszelegoztam a megoldást, ti ezt értitek? Úgy érzem, hogy feleslegesen toltam túl a dolgot:

    const onlySelectable = allOptions
      ?.filter((e: { etype: string }) => e === 'SELECTABLE')
      .map(({ eorder, eid }) => ({ eorder, eid }));

    const filterAndAddOrderNum = (
      selectionHistory: { eid: string, selectedOption: string }[],
     onlySelectable: { eorder: number; eid: string }[]
    ) => {
      const map = new Map();
      const filteredSelectionHistory = selectionHistory?.selections?.filter(({ eid: id1 }) =>
       onlySelectable.some(({ eid: id2 }) => id1 === id2)
      );
     filteredSelectionHistory.forEach((item) => map.set(item.eid, item));
     onlySelectable.forEach((item) =>
        map.set(item.eid, { ...map.get(item.eid), ...item })
      );

      return Array.from(map.values());
    };


    Lényegében van egy forrás JSON ami mindig a friss adatokat tartalmazza, az eorder változhat es nekem az alapján kell sorrendben megjelentetni az adatokat, illetve van egy history JSON ahol eddig csak az id es a user opciója volt elmentve. A feladat, hogy miután megkaptam a forrást es a history-t szinkronizáljam azokat. Tehát a redux state-ben a history-bol kinyert eid-hoz csatoljam eorder-t, igy a frissen megjelenített adatok es a history-bol jövő adatok is szinkronban lennének, mert időközben a sorrend es a tartalom is változhat. Az esetleg (user által) ujra elküldött adatoknak is tukrozniuk kell a forrásban történt változást.

    Nem feltétlen 1 liner megoldást keresek sõt, de egy másod véleménynek örülnék, hogy lehet-e ezt egyszerűbben is.

    Ez a "selectionHistory?.selections?.filter" js szintaxis egyáltalán? Sosem láttam ilyet, de kezdem elveszíteni a fonalat a nyelvvel kapcsolatban, annyira gyorsan változik.

  • martonx
    veterán

    Előre is elnézést az auto-correctes felig ékezetes, felig magyar, felig angol kommentert.

    Mivel magamtol nem jöttem ra ezért osszelegoztam a megoldást, ti ezt értitek? Úgy érzem, hogy feleslegesen toltam túl a dolgot:

    const onlySelectable = allOptions
      ?.filter((e: { etype: string }) => e === 'SELECTABLE')
      .map(({ eorder, eid }) => ({ eorder, eid }));

    const filterAndAddOrderNum = (
      selectionHistory: { eid: string, selectedOption: string }[],
     onlySelectable: { eorder: number; eid: string }[]
    ) => {
      const map = new Map();
      const filteredSelectionHistory = selectionHistory?.selections?.filter(({ eid: id1 }) =>
       onlySelectable.some(({ eid: id2 }) => id1 === id2)
      );
     filteredSelectionHistory.forEach((item) => map.set(item.eid, item));
     onlySelectable.forEach((item) =>
        map.set(item.eid, { ...map.get(item.eid), ...item })
      );

      return Array.from(map.values());
    };


    Lényegében van egy forrás JSON ami mindig a friss adatokat tartalmazza, az eorder változhat es nekem az alapján kell sorrendben megjelentetni az adatokat, illetve van egy history JSON ahol eddig csak az id es a user opciója volt elmentve. A feladat, hogy miután megkaptam a forrást es a history-t szinkronizáljam azokat. Tehát a redux state-ben a history-bol kinyert eid-hoz csatoljam eorder-t, igy a frissen megjelenített adatok es a history-bol jövő adatok is szinkronban lennének, mert időközben a sorrend es a tartalom is változhat. Az esetleg (user által) ujra elküldött adatoknak is tukrozniuk kell a forrásban történt változást.

    Nem feltétlen 1 liner megoldást keresek sõt, de egy másod véleménynek örülnék, hogy lehet-e ezt egyszerűbben is.

    jsfiddle, codepen működő példát ha küldenél nekünk, talán nagyobb kedvvel nézne rá bárki is.

  • _ak_
    addikt

    Nem biztos, hogy kimondottan JS kérdés, de React appbanan i18n-t használok, ahol a doksi szerint importálni kell az egész config fájlt, hogy bekerüljön a bundlebe. Közben létrehoztam benne egy functiont is és azt később külön is importáltam:

    import "./i18n";
    import { getTranslations } from "./i18n";

    Szükségem van az eredeti importra ebben az esetben?

    Jó ez hülye kérdés volt, mentségemre szóljon, hogy előszőr kerültem ilyen helyzet elé.
    Persze hogy anélkül is működik, nem is tudom hol jártam...

  • martonx
    veterán

    Köszi, végül ez lett belőle:

    const account: IAccount | null = useAccount(accounts[0] || {});
    const customProp: string | undefined =
      account?.idTokenClaims?.extension_customProp;

    Ahogy mondtad az AccountInfo lehet null is, emiatt a customProp lehet undefined is), amit használata előtt ellenőrzök, így a helyére került minden. :R

    Jim-Y:

    Kipróbáltam ezt is, de ugyan az maradt a figyelmeztetés.

    coco2:

    Távol álljon tőlem, hogy megmondjam a frankót, de ha engem kérdezne valaki, hogy érdemes-e a TS-el foglalkozni, akkor azt tanácsolnám, hogy ne is kezdjen bele semmibe anélkül, legalábbis, ha programozásból akar megélni és JS vonalon mozog.

    Nekem nagyon vegyes a TS megítélésem. Nodejs projektbe nem kezdenék bele TS nélkül. Miközben kliens oldalon meg nem szopatnám magam TS-el. Kivétel react, angular amik már önmagukban is szopások, azoknál a TS már inkább ismét javít a szarkupacon.

  • Jim-Y
    veterán

    Valóban, figyelmetlen voltam a customProp egy string a végére és rossz helyen deklaráltam.

    const account: IAccount = useAccount(accounts[0] || {});
    const customProp: string = account?.idTokenClaims?.extension_customProp;

    Így megoldódik a customProp kérdése, de az accountra ezt kapom:

    TS2322: Type 'AccountInfo | null' is not assignable to type 'IAccount'. Type 'null' is not assignable to type 'IAccount'.

    A useAccount:
    // Given 1 or more accountIdentifiers, returns the Account object if the user is signed-in
    export declare function useAccount(accountIdentifiers: AccountIdentifiers): AccountInfo | null;

    const account: IAccount = useAccount(accounts[0] || {} as IAccount);

  • coco2
    őstag

    Nekem erről egyből a Modernizr jutott eszembe, de nem tudom, hogy mennyire divatos még használni.

    Más.

    Ugyan csak lassacskán, de ismerkedem a TypeScripttel és van valami ami nem tudom, hogy miért nem működik. Az MS Authentication Libraryban adott egy type definition:

    export declare type AccountInfo = {
        homeAccountId: string;
        environment: string;
        tenantId: string;
        username: string;
        localAccountId: string;
        name?: string;
        idTokenClaims?: object;
    };

    AzA React komponensemben szeretnék hozzáférni egy custom idTokenClaimshez:

    const { accounts } = useMsal();
    const account = useAccount(accounts[0] || {});
    const customProp: IAccount = account?.idTokenClaims?.extension_customProp;

    Az account definíciója az AccountInfo. Az IAccount egy általam létrehozott interface, ahol az AccountInfo-t próbálom kibővíteni, lovasítom alapján ennek működnie kellene:

    interface IAccount extends AccountInfo {
      idTokenClaims: {
       extension_customProp: string;
      };
    }

    De akárhogy csavarom a dolgot az .extension_customProp-ra mindig azt kapom, hogy
    TS2339: Property 'extension_customProp' does not exist on type 'object'.

    Hol rontom el?

    TS/ES - a magam részéről nem erőltetném. ES6-nak anno örültem, de csak addig, míg le nem esett róla, mekkora egy fail. Kb olyan fejlettségi szinten van, mint anno a php3. Pihentetni kellene legalább fél évtizedet, és majd megnézni utána.

  • Silεncε
    őstag

    Valóban, figyelmetlen voltam a customProp egy string a végére és rossz helyen deklaráltam.

    const account: IAccount = useAccount(accounts[0] || {});
    const customProp: string = account?.idTokenClaims?.extension_customProp;

    Így megoldódik a customProp kérdése, de az accountra ezt kapom:

    TS2322: Type 'AccountInfo | null' is not assignable to type 'IAccount'. Type 'null' is not assignable to type 'IAccount'.

    A useAccount:
    // Given 1 or more accountIdentifiers, returns the Account object if the user is signed-in
    export declare function useAccount(accountIdentifiers: AccountIdentifiers): AccountInfo | null;

    Igen, mivel a hook visszatérési típusa nem IAccount, hanem IAccount | null union, ezért csak siman IAccount típus nem lehet a tároló konstans típusa. Az account konstans típusa legyen ugyanúgy IAccount | null és úgy már jó lesz (a ?. le fogja kezelni, ha ott null van (de azt is kezeli, ha undefined), olyankor a string konstans értéke is undefined lesz)

  • Silεncε
    őstag

    Nekem erről egyből a Modernizr jutott eszembe, de nem tudom, hogy mennyire divatos még használni.

    Más.

    Ugyan csak lassacskán, de ismerkedem a TypeScripttel és van valami ami nem tudom, hogy miért nem működik. Az MS Authentication Libraryban adott egy type definition:

    export declare type AccountInfo = {
        homeAccountId: string;
        environment: string;
        tenantId: string;
        username: string;
        localAccountId: string;
        name?: string;
        idTokenClaims?: object;
    };

    AzA React komponensemben szeretnék hozzáférni egy custom idTokenClaimshez:

    const { accounts } = useMsal();
    const account = useAccount(accounts[0] || {});
    const customProp: IAccount = account?.idTokenClaims?.extension_customProp;

    Az account definíciója az AccountInfo. Az IAccount egy általam létrehozott interface, ahol az AccountInfo-t próbálom kibővíteni, lovasítom alapján ennek működnie kellene:

    interface IAccount extends AccountInfo {
      idTokenClaims: {
       extension_customProp: string;
      };
    }

    De akárhogy csavarom a dolgot az .extension_customProp-ra mindig azt kapom, hogy
    TS2339: Property 'extension_customProp' does not exist on type 'object'.

    Hol rontom el?

    Szerintem: Az useAccount visszatérhet sima objecttel is (én erre következtetek a paraméterben átadott üres object miatt)? Akkor viszont a TS jogosan reklamál, hiszen ott az account típusa nem IAccount lesz, hanem IAccount | object “union”, az objecten pedig nem fogja megtalálni az adott propot.

    Illetve az az IAccount típusdeklaráció sincs szerintem jó helyen, annak az account konstanson kene legyen, a customProp az interface szerint string típusú

  • coco2
    őstag

    Sziasztok,

    nem kimondottan JS téma, de azért kapcsolódik. 2 React app között szeretnék valós idejű kapcsolatot létrehozni. Az egyik egy kliens app, a másik egy manager app.
    Leegyszerűsítve chat és szavazás lebonyolítása a cél. A manager appból kellene indítani a szavazást ami a kliensen jelenik meg egy modal ablakban, illetve amikor kezdődik az esemény akkor átirányítani a usert a megfelelő oldalra.

    Mivel Azure környezetben vagyunk így adta volna magát a SignalR és mivel a consumption plan a cél, abból is a serverless változat upstreammel megfűszerezve...de itt teljesen összekuszálódik minden. MS doksik meglehetősen foghíjasak.
    Most gyakorlatilag ott tartok, hogy azt sem tudom, hogy mit lehet megcsinálni és mit nem ebben a felállásban.

    Van aki foglalkozott signalR-el és valamelyest nyomonköveti a fejlesztését? Érdemes tovább erőltetni a serverless megközelítést, ki tudja váltani a 'default' signalR-t?

    Ami most lelőtte a biztosítékot, hogy a manager appban tudni kellene ki csatlakoztak. Simán a serverless nem tudja, de az upstream tud onConnected eventet küldeni, dokisk írják is, hogy hogyan lehet az upstreamet 'beállítani'. De itt el is fogy a segítség, a function appban lehet egyáltalán ilyenkor JS-t használni vagy ez még CSHARP kiváltság? Ráadásul a serverless példák sima POST-ok, de úgy tűnik, hogy külön vannak bind-ok is az upstreamhez...

    Ha kesze-kuszának tűnik amit írtam, akkor elnézést, de jól tükrözi a jelenlegi állapotomat.

    Az upstream szerver irányú kapcsolat. Hogy mit nevezel serverless-nek egy webes alkalmazás esetében, ahol létezik upstream, na azon kicsit vakarom a buksit. Valami zavart érzek az erőben :) Minimum egy tracker biztosan kell, és az már szerver. A "POST" tipikusan szerver irányba küldött http kérés, és nem csak dotnetc kiváltság. Js esetében xhr van kommunikációra, és abszolút alkalmas post kérések küldésére. A react meg signalr nem az én világom, abban talán a többiek segítenek.

  • martonx
    veterán

    Sziasztok,

    nem kimondottan JS téma, de azért kapcsolódik. 2 React app között szeretnék valós idejű kapcsolatot létrehozni. Az egyik egy kliens app, a másik egy manager app.
    Leegyszerűsítve chat és szavazás lebonyolítása a cél. A manager appból kellene indítani a szavazást ami a kliensen jelenik meg egy modal ablakban, illetve amikor kezdődik az esemény akkor átirányítani a usert a megfelelő oldalra.

    Mivel Azure környezetben vagyunk így adta volna magát a SignalR és mivel a consumption plan a cél, abból is a serverless változat upstreammel megfűszerezve...de itt teljesen összekuszálódik minden. MS doksik meglehetősen foghíjasak.
    Most gyakorlatilag ott tartok, hogy azt sem tudom, hogy mit lehet megcsinálni és mit nem ebben a felállásban.

    Van aki foglalkozott signalR-el és valamelyest nyomonköveti a fejlesztését? Érdemes tovább erőltetni a serverless megközelítést, ki tudja váltani a 'default' signalR-t?

    Ami most lelőtte a biztosítékot, hogy a manager appban tudni kellene ki csatlakoztak. Simán a serverless nem tudja, de az upstream tud onConnected eventet küldeni, dokisk írják is, hogy hogyan lehet az upstreamet 'beállítani'. De itt el is fogy a segítség, a function appban lehet egyáltalán ilyenkor JS-t használni vagy ez még CSHARP kiváltság? Ráadásul a serverless példák sima POST-ok, de úgy tűnik, hogy külön vannak bind-ok is az upstreamhez...

    Ha kesze-kuszának tűnik amit írtam, akkor elnézést, de jól tükrözi a jelenlegi állapotomat.

    Én C#-pal egyik régi projektben évek óta használok SignalR-t. És nemrég egy POC erejéig az Azure-os Serverless SignalR-t is kipróbáltam. Szépen tette a dolgát. Viszont tagadhatatlan, hogy nem éppen kezdőbarát a dolog.
    És hogy ez nodejs-el mennyire működik, arról lövésem sincs.

  • cocka
    veterán

    Nem igazán js, de hátha: [link]

    Ez jó lenne, csak éppen ez minden oldalnál figyelmeztet, amit viszont nem akarok. Viszont ha tudom melyik jsben van a refresh marhaság, akkor azt adblockkal esetleg le tudom tiltani.

  • martonx
    veterán

    Sziasztok!

    A következőben szeretnék tőletek egy kis iránymutatást kérni.
    Egy olyan "weboldalra" lenne szükség, amit 99%-ban mobilról vagy tabletről használnának. Nálunk jelenleg, válogatás nélkül, mindent drupallal oldanak meg, amit Zurb Foundation-el alakítok mobil készre. Általában ennyi elég is, de jelen esetben úgy érzem, hogy nem a legjobb megoldás.
    Véleményem szerint remek választás lenne a Foundation for Apps keretrendszer használata és a drupal csak a backend részét töltené be, ami JSON adatokat küld, tehát utóbbi tényleg csak tartalomkezelésre lenne használva, míg előbbinek csak meg kell jelenítenie azt.

    A gondom az, hogy eddig nem dolgoztam még ilyen formában sem javascriptel, sem JSON adattal. Nem tudom, hogy hogyan lehetne a kettőt összehozni.

    Egyrészt nektek erről mi a véleményetek, másrészről pedig találkoztatok-e ilyen vagy ilyesmi párosítással? Én sajnos elbuktam a google teszten és nem is tudom, hogy merre induljak, hogy ez működjön, így ha jó az ötlet, akkor szükségem lenne egy pár kulcsszóra, vagy jó tutorialra, amin el tudnék indulni. :R

    Amit te szeretnél az egy single page application, amit Karma jól be is mutatott. Annyit tennék még hozzá, hogy ebben az esetben a helyetekben a drupalt abszolút mellőzhetném, csak rest apu kell alá. De érted, így meg bukod a komplett Cms funkcionalitást. Neked kell dönteni, marad a cms bubusság és szar végeredmény gyorsan összekattogtatva, vagy megírjátok normálisra spa-ként, mondjuk 10-szer akkora idő befektetéssel.

  • Karma
    félisten

    Sziasztok!

    A következőben szeretnék tőletek egy kis iránymutatást kérni.
    Egy olyan "weboldalra" lenne szükség, amit 99%-ban mobilról vagy tabletről használnának. Nálunk jelenleg, válogatás nélkül, mindent drupallal oldanak meg, amit Zurb Foundation-el alakítok mobil készre. Általában ennyi elég is, de jelen esetben úgy érzem, hogy nem a legjobb megoldás.
    Véleményem szerint remek választás lenne a Foundation for Apps keretrendszer használata és a drupal csak a backend részét töltené be, ami JSON adatokat küld, tehát utóbbi tényleg csak tartalomkezelésre lenne használva, míg előbbinek csak meg kell jelenítenie azt.

    A gondom az, hogy eddig nem dolgoztam még ilyen formában sem javascriptel, sem JSON adattal. Nem tudom, hogy hogyan lehetne a kettőt összehozni.

    Egyrészt nektek erről mi a véleményetek, másrészről pedig találkoztatok-e ilyen vagy ilyesmi párosítással? Én sajnos elbuktam a google teszten és nem is tudom, hogy merre induljak, hogy ez működjön, így ha jó az ötlet, akkor szükségem lenne egy pár kulcsszóra, vagy jó tutorialra, amin el tudnék indulni. :R

    A kontextus meg a helyzeted pontosabb ismerete nélkül (pl. a kódbázis minősége) nehéz testreszabott választ adni, de amit most leírtál, a mai gyakorlatban elég népszerű Single Page Application (~ webes vastag kliens) stratégia. (Egy kulcsszónak használhatod az SPA-t.)

    Ennek van előnye és hátránya egyaránt, hogy néhányat soroljak:
    + Jobb érzékelt sebesség/felhasználói élményt nyújt az első betöltés után.
    + Kényszerűen tisztább az architektúra, jobban újrafelhasználható (pl. natív mobilalkalmazások, új UI...) a monolit projekt kettévágása miatt(*).
    + A részek önálló életciklussal bírnak, tehát több csapat könnyebben dolgozhat a részeken; külön tesztelhető és élesíthető minden elem.
    + A backendhez és a frontendhez is vannak specializált könyvtárak, ahelyett hogy egy eszközzel próbálnád egy n-tier alkalmazás minden aspektusát lefedni. (igen, még mindig nem szeretem a PHP-t)

    - JavaScript nélkül (pl. NoScript felhasználók) az egész történet halott, úgyhogy egy igazán univerzális megoldáshoz nem dobhatod ki a Drupal által generált önjáró, "ódivatú" oldalt.
    - A böngészők közötti eltérések sose szűnnek meg. (Safari is the new IE :( )
    - Nagyon könnyű tévútra menni, és ennek következtében (abszolút és UX-es értelemben is) lassú, működésében hibás, neadjisten biztonságilag kockázatos kódot írni!
    - Tanulni kell. Egy tiszta JS alkalmazás ég és föld ahhoz a szinthez képest, amikor egy sablonból generált HTML oldal kis szakaszait jQueryvel ugráltatja az ember. Az azzal kapcsolatos tapasztalatok inkább veszélyesek, mint hasznosak.

    (*): Ehhez igazából nem kell SPA, csak egy jó környezet meg önfegyelem. Például a legtöbb értelmes MVC megvalósításban teljesen független az üzleti logika a HTML generálástól (megjelenítéstől).

    Személy szerint Drupalt soha nem használtam, a Foundationt is csak kerülgettem (inkább Bootstrapeztem); de az elgondolás nemes, és ha a szerveroldalad képes az adatait strukturált formában kiadni, szerintem mindenképpen megér egy próbát. Sajnos nem tudom, hol lehetne jól elindulni nulláról, bár az Angular 1.4-hez az ng-book elég bíztató. Valaki segítsen ki! :)

  • Sk8erPeter
    nagyúr

    Köszi! Egyszerű és nagyszerű, meg sem fordult a fejemben, hogy 'id'-ra tegyem a formázást...

    Már csak azon töprengek, hogy hogyan kerüljem meg a firefox background-image transition hiányát, de chrome alatt szépen működik. :R

    "Egyszerű és nagyszerű, meg sem fordult a fejemben, hogy 'id'-ra tegyem a formázást..."
    Még jó is, hogy nem fordult meg a fejedben, mert illik sokkal általánosabban megoldani az ilyesmit, nem pedig id-vel szórakozni, és ezzel kb. örökre rögzíteni, hogy melyik elemet is fogod buzerálni. Vannak esetek, amikor ez nem számít, de többnyire mégis.

    Amúgy örülök, hogy nálad működik a "javított" demó, mert nálam konkrétan semmit nem csinál, igaz, összesen 5 másodpercnyi időt töltöttem a kipróbálásával, nem próbáltam elgondolkozni, mit csinál és mit kellene csinálnia. :D

  • Speeedfire
    félisten

    Köszi! Egyszerű és nagyszerű, meg sem fordult a fejemben, hogy 'id'-ra tegyem a formázást...

    Már csak azon töprengek, hogy hogyan kerüljem meg a firefox background-image transition hiányát, de chrome alatt szépen működik. :R

    Én lehet valami olyasmi módot választanék rá, ami nem background-image-t használ hanem, olyasmi mint a carousel. Ott akár lehetne slideUp(), slideDown() effektet használni akár. Vagy show('slow'), hide('slow') effektet. Nem tudom milyen most az oldal felépítése.

  • Speeedfire
    félisten

    Sziasztok!

    Egy kis segítségre lenne szükségem, hogy merre induljak el.

    Vagy egy divem, aminek a hátterét szeretném változtatni, másik thumbnail div-re való kattintástól függően.
    Addig eljutottam, hogy jó lenne a div class-t változtatni és annak függvényében, más css töltődik be rá. De ez a toggleClass nem épp úgy csinálja , ráadásul jó lenne, ha esetleg valami átmeneti animáció is lenne képváltogatás közben.

    Ilyen, de ugye ez így nem vállalható, csak nem tudom, hogy mit lenne érdemes még megnézni.

    [link], css-el meg adsz neki animációt.

Új hozzászólás Aktív témák

Hirdetés