Security News
Supply Chain Attack Detected in @solana/web3.js Library
A supply chain attack has been detected in versions 1.95.6 and 1.95.7 of the popular @solana/web3.js library.
Wrapper around localStorage (and other stores) to easily store JSON objects.
Supports:
If you want to store client-side data for your website, the way to do it is with localStorage. However, there is at least one siginificant downside: you can only store strings in localStorage keys.
The best way to get around this is by storing a stringified JSON object in a key, but doing this manually or having to call a function that does it for you any time you change an object would be annoying.
This library solves these problems using JS proxies.
It also has great IDE support thanks to it being written in TypeScript.
You can also use it with vanilla JS with the Webpacked file (ls-proxy.user.js
or ls-proxy.min.user.js
),
which is useful to test it in the browser, when not using a JS bundler, or while writing UserScripts.
Here's all it takes to store a stringifed JSON object in localStorage and automatically change it:
import { storeObject } from 'ls-proxy'
const someInfo = storeObject(
// The localStorage key to save data under
'someInfo',
// The object to store
{
aString: 'Hello, World!',
aNumber: 123,
aBoolean: true,
aList: [1, '2', 3],
},
)
someInfo.aNumber = 42 // Updates localStorage
console.log(someInfo.aList) // Reads from localStorage
The method above stores an entire serialized object in localStorage, meaning the entire object has to be stringified/parsed whenever a single key is affected. The method below stores each key individually instead:
import { storeSeparate } from 'ls-proxy'
const someInfo = storeObject(
// The object to store
{
aString: 'Hello, World!',
aNumber: 123,
aBoolean: true,
aList: [1, '2', 3],
},
// Optional; prefixes the stored keys with this ID
{ id: 'someInfo' },
)
someInfo.aNumber = 42 // Updates localStorage
console.log(someInfo.aList) // Reads from localStorage
If you have any value stored in a store that requires some extra action to trigger an update,
then using ls-proxy to create a custom store is a good option.
One example of this is React (and many other frontend UI's) state, which has to be updated by calling
a setState
function instead of just mutating the value returned.
When using ls-proxy
, state will be updated even if deeply nested objects' keys are modified.
You can override the get
and set
methods to automatically set/retrieve values from your other store:
import { storeSeparate } from 'ls-proxy'
const myObj = storeSeparate({ foo: 'bar' },
{
get(key) {
// Logic to get a key here
}
set(key, value) {
// Logic to set a key here
}
// Important!!
// If your store only accepts strings, then don't override this method
// If it accepts other values such as objects, then override it as shown
// This makes sure that the proxy created by ls-proxy isn't accidentally stored,
// which could cause a lot of very painful-to-find bugs
stringify(value) {
if (typeof value == 'object') return JSON.parse(JSON.stringify(value))
return value
}
})
To make a function to construct these objects, it's a good idea to still let the user pass in config options.
You can copy the signature from storeObject
or storeSeparate
as long as it's credited as described
by the project's licenses.
Here's an example:
import { storeSeparate, StoreSeparateOptions } from 'ls-proxy'
// The options for your store function
// This should extend the original function's options, omitting those that your function overrides
type Options<O extends Record<string, any>> = Omit<
StoreSeparateOptions<O>,
'get' | 'set'
>
function storeCustom<O extends Record<string, any>>(
defaults: O,
configuration: Options<O>,
): O {
return storeSeparate(defaults, {
...configuration,
get(key) {
// Logic to get a key here
},
set(key, value) {
// Logic to set a key here
},
})
}
Documentation for the main branch is hosted at https://ls-proxy.adamts.me.
Documentation can be built from a cloned repository by running yarn doc
.
Examples are located in examples
.
storeSeparate
will generally be faster than storeObject
since there's less data being serialized/deserialized with each get/set,
but there are still reasons to use storeObject
.
For example, if you want to use validate
and modify
(see documentation for config options),
and you need the entire object for context.
This can be the case if you need another key's value to validate the object,
or if you want to modify multiple keys with a single set/get.
Because of the customization offered in the options of storeObject
and storeSeparate
,
it's possible to define custom stores other than localStorage.
These can be made by overriding the get
and set
methods via the config options.
There are some custom stores already built in in the factories
subfolder:
ls-proxy/factories/react
)See For other stores for a brief explanation about how to set one up.
To use in a Node project, add ls-proxy as a dependency.
# npm
npm install ls-proxy
# yarn
yarn add ls-proxy
You can then import and use functions:
import { storeObject } from 'ls-proxy'
const myObj = storeObject('myObj', {
name: 'John',
age: 21,
})
myObj.name = 'Joe'
myObj.age++
In a UserScript that isn't built with some build tool, you can @require
the library:
// @require https://gitlab.com/MysteryBlokHed/ls-proxy/-/raw/main/ls-proxy.user.js
You can replace main
with a specific release tag like v0.1.0
to require a specific version:
// @require https://gitlab.com/MysteryBlokHed/ls-proxy/-/raw/v0.1.0/ls-proxy.user.js
Each release tag also has a minified version of the script available,
which can be used by changing the file extension to .min.user.js
:
// @require https://gitlab.com/MysteryBlokHed/ls-proxy/-/raw/v0.1.0/ls-proxy.min.user.js
Functions are available on the global LSProxy
object:
const { storeObject } = LSProxy
const myObj = storeObject('myObj', {
name: 'John',
age: 21,
})
myObj.name = 'Joe'
myObj.age++
The types included with the npm package still work when the library is @require
'd.
Just add the types as a dev dependency for a Node project or install them globally.
With the package installed, include the following reference line somewhere in your TypeScript source file:
/// <reference types="ls-proxy" />
Building this project requires Node.js and Yarn. To install dependencies, run:
yarn install
To build the project, run:
yarn build
To automatically build when a source file is modified, run:
yarn dev
Built JS files and type declarations will be placed in the lib/
directory,
and the UserScript will be placed in the root. The package.json
file is configured
to publish files in the lib/
directory to npm.
To test the project, run:
yarn test
This project uses Jest for tests.
This project is licensed under either of
at your option.
This project was created from a template licensed under the MIT license (LICENSE or http://opensource.org/licenses/MIT).
0.6.0
FAQs
Wrapper around localStorage (and other stores) to easily store JSON objects
The npm package ls-proxy receives a total of 1 weekly downloads. As such, ls-proxy popularity was classified as not popular.
We found that ls-proxy demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
A supply chain attack has been detected in versions 1.95.6 and 1.95.7 of the popular @solana/web3.js library.
Research
Security News
A malicious npm package targets Solana developers, rerouting funds in 2% of transactions to a hardcoded address.
Security News
Research
Socket researchers have discovered malicious npm packages targeting crypto developers, stealing credentials and wallet data using spyware delivered through typosquats of popular cryptographic libraries.