HowTo: cache Graphcool endpoint data for offline use

Does anyone know how to cache graphcool data for continued use in an app in an offline state?
https://stackoverflow.com/questions/44030489/howto-cache-graphcool-data-for-offline-use

@TheoMer you have to cache dynamic network requests manually, either in ServiceWorker or in main thread.


Catalog types & AdditionalCatalogRegistryModule interface

Sometimes i would like to have a multiple CatalogType caches (ie AdditionalCatalogRegistryModule) to be managed by a single class/service.
In java its not possible to do
public class SomeClass implements AdditionalCatalogRegistryModule<A>, AdditionalCatalogRegistryModule<B>
Would it be possible to add an optional way to controll the flow with annotations?
@Service
public class SomeService {

    @CatalogModule.getById(A.class)
    public Optional<A> getAById(String id);

    @CatalogModule.getById(B.class)
    public Optional<B> getBById(String id);

    @CatalogModule.registerCatalogType(A.class)
    public void registerAdditionalCatalog(A extraCatalog)

    @CatalogModule.registerCatalogType(B.class)
    public void registerAdditionalCatalog(B extraCatalog)

    @CatalogModule.getAll(A.class)
    public Collection<A> getAllOfA(A extraCatalog)

    @CatalogModule.getAll(B.class)
    public Collection<B> getAllOfB(B extraCatalog)

This would allow us to have multiple catalog caches within a single class, thus reducing boilerplate which is currently neccessary to create AdditionalCatalogRegistryModules.

Do you want to create a cache or add a new registry module?
What would be your use-case?
Why do you need two or more different catalog classes in one class?
Have you considered creating delegating wrappers that each handle a single type?

Do you want to create a cache or add a new registry module?

Thats the same thing? At runtime all catalog types are cached.

What would be your use-case?

Something like:
public class SomeClass implements AdditionalCatalogRegistryModule<A>, AdditionalCatalogRegistryModule<B>

Why do you need two or more different catalog classes in one class?

Why do i need to create a new class for each catalog?

Have you considered creating delegating wrappers that each handle a single type?

boilerplate code

Why do you need two or more different catalog classes in one class?

Why do i need to create a new class for each catalog type?

Separation of concerns, or are they that closely related? Probably yes.

Have you considered creating delegating wrappers that each handle a single type?

boilerplate code which can be fixed only on sponge side

Aside from the class declaration and the imports (that any IDE will generate for you), you will still have the same amount of actual code.
You might be able to omit most of the code if you relied on inheritance / API provided CatalogRegistryModule implementations, though.

Would something like this help you?
GameRegistry

createImmutableCatalogModule(Class<T>, Collection<? extends T>) : CatalogRegistryModule
createMutableCatalogModule(Class<T>) : AdditionalCatalogRegistryModule

or have implementations of those two variants available in the API?

Why do you need two or more different catalog classes in one class?

Why do i need to create a new class for each catalog type?

Separation of concerns, or are they that closely related? Probably yes.

The things are closely related, all of these CatalogTypes are handled by same logic in the same guice Singleton.

you will still have the same amount of actual code.

Here a previous attempt of mine:
https://github.com/SpongePowered/SpongeAPI/pull/1385

Why would you use a Supplier?

Closed by https://github.com/SpongePowered/SpongeAPI/commit/98980a85e9c4f980da0d74665b181e745ac33859#diff-635f7cffdfc7e01562476fc29e79a663
AdditionalCatalogRegistryModule (and most of the registry framework) is gone


Added way to position skills better

Changed the skills object so skills are organized by position and added null skills where spaces are needed to match in game look.
Also changed skill icons to be named by position since null skills would offset the current naming scheme.

Hi @McAJBen I like the idea of this change! It seems like you did a lot of work. But I didn't see a change to the layout when I ran the site locally. Also, I can't merge this until the conflicts are resolved.

@seigler I'll take a look at getting this up to date.
The main difference is when the row of skills has one or two skills. For instance in Moze's Demolition Woman tree she has multiple rows with two skills each. In game some are positioned with a space in the middle or at the end unlike the current website.


refactor(semantic): remove duplicated code

#7276  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @overlookmotel and the rest of your teammates on  Graphite


@ItemBuy act is incorrect

When using the @ItemBuy trigger act is documented as the item the player will receive however act is the item(s) stored on the NPC.
If you do the following the item on the NPC is deleted.
[EVENT fortheplayer]
ON=@ItemBuy
act.remove

Can't reproduce, the item is properly removed from the vendor list

In your player event  in the @Itembuy trigger use this
serv.log  buying <act.name> from <argo.name>

@drk84 yep.. and what it should do is delete in the player bag not the vendor one

Basically ACT is equals to the item on the vendor, not the item on the player's backpack. Because ItemBuy called before buying the item, so the new item haven't been created yet, so there is no way to get new item under @ItemBuy trigger. Also even we add new trigger that called after player bought and item, there could be issues also, for example, some items like armors, not stackable, so what happens if you buy 10 platemail gauntlets? Which one gonna be ACT? Can be saved as a list, or list of locals but is it really worth to do it? Because if you want to remove the items they bought you can just start 1 sec timerf and check player backpack for <act.baseid> and consume <act.amount> <act.baseid> from player.

I close this