elder_scrolling/src/cards/Cards.tsx

103 lines
2.6 KiB
TypeScript
Raw Normal View History

2020-09-15 20:27:31 +00:00
import * as React from "react";
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
import { useState, useEffect, useRef } from "react";
import { Loading } from "./Loading";
import { Card } from "./Card";
import { JustifiedLayout, GridLayout } from "@egjs/react-infinitegrid";
import ReactModal from "react-modal";
import { FullCard, fullcardStyles } from "./FullCard";
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
import {
CardProps,
CardRequestProps,
CardState,
CardStateHandler
} from "./types";
2020-09-15 20:27:31 +00:00
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
const PAGE_SIZE = 20;
const firstUrl = `https://api.elderscrollslegends.io/v1/cards?pageSize=${PAGE_SIZE}&page=1`;
const emptyCards: CardState = {
cards: [],
next: firstUrl,
maxCards: -1
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
};
export const Cards = () => {
const [cards, setCards]: CardStateHandler = useState(emptyCards);
const [loading, setLoading]: [boolean, Function] = useState(false);
const [currentCard, setCurrentCard]: [CardProps | null, Function] = useState(
null
);
const loadItems = () => {
if (cards.next === null || cards.cards.length === cards.maxCards) {
return;
}
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
setLoading(true);
const request = new Request(cards.next);
fetch(request)
.then(response => response.json())
.then((data: CardRequestProps) => {
setCards({
cards: [...cards.cards, ...data.cards],
next: data._links && data._links.next ? data._links.next : null,
maxcards: data._totalCount
});
setLoading(false);
});
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
};
const loadMoreCards = (options: any) => {
if (options.startLoading !== null) {
options.startLoading();
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
}
loadItems();
};
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
const onLayoutComplete = (options: any) => {
!options.isLayout && options.endLoading();
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
};
const handleCloseCard = () => {
setCurrentCard(null);
};
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
const handleOpenCard = (id: string) => {
const card = cards.cards.find(card => card.id === id);
if (card) {
setCurrentCard(card);
}
};
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
return (
<div className="container">
<ReactModal
isOpen={currentCard !== null}
style={fullcardStyles}
contentLabel=""
onRequestClose={handleCloseCard}
>
<FullCard card={currentCard} />
</ReactModal>
<GridLayout
options={{
isConstantSize: true,
isEqualSize: true,
transitionDuration: 0.2
}}
layoutOptions={{
margin: 10
}}
onAppend={loadMoreCards}
onLayoutComplete={onLayoutComplete}
>
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
{cards.cards.map((card: CardProps, count: number) => (
<Card card={card} key={count} onClick={handleOpenCard} />
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
))}
</GridLayout>
{loading ? <Loading /> : ""}
FEAT Infinite scroll works. Sort-of. I've implemented a Cards/Card interface, but it's heavy and direct, with absolutely not a care in the world about how much memory your browser can give me. It only moves forward in time, and accumulates as it goes. The React is brutal and heavy, but for a prototype, eh... it's a prototype. I'm a firm believer in prototypes. Criticism: "Cards" is doing too much, and not enough. It would make more sense to have a moving window, showing no more than what it would take to show the user what is expected at that moment, with the ability to load high and low, keeping only what the user is _looking at_ in the DOM tree. Proposal: Cards needs a CardCollection proxy object, which the Cards view object (personal convention: TSX files are named for what they show, semantically; TS files may be suffixed with "Model" or "Collection", a'la Backbone, to seperate them from the views, if needed; "Model" objects are very rarely needed) taps it as the user moves up and down; the IntersectionObserver tool would be pretty good for this; and if the proxy actually _cached_ the fields it had already seen, it wouldn't be slow at all. The proxy object could also support the search feature by keeping two collections: one of the "whole" set, and one of the "last search" set; the proxy could swap between them as needed. Enhancement: Well, it could use a "zoom" feature with a nice overlay. It might even be lovely to have a second page with all the things I haven't shown, like attributes, subtype, rarity (not, not the pony), or keywords. Enhancement: It is possible to search based on set, attributes, and so forth, so a sidebar with those as filters would also be kinda cool.
2020-09-16 02:41:37 +00:00
</div>
);
};