happycode-storage
Happycode Storage is a library for loading and storing project and asset files for Happycode 3.0

Installation
This requires you to have Node.js installed.
In your own Node.js environment/application:
npm install https://gitee.com/happycoding-cx/happycode-storage.git
If you want to edit/play yourself (requires Git):
git clone https://gitee.com/happycoding-cx/happycode-storage.git
cd happycode-storage
npm install
Using happycode-storage
From HTML
<script src="happycode-storage/dist/web/happycode-storage.js"></script>
<script>
var storage = new Happycode.Storage();
</script>
From Node.js / Webpack
var storage = require('happycode-storage');
Storage API Quick Start
Once you have an instance of happycode-storage, add some web sources. For each source you'll need to provide a function
to generate a URL for a supported type of asset:
var getAssetUrl = function (asset) {
var assetUrlParts = [
'https://assets.example.com/path/to/assets/',
asset.assetId,
'.',
asset.dataFormat,
'/get/'
];
return assetUrlParts.join('');
};
Then, let the storage module know about your source:
storage.addWebStore(
[AssetType.ImageVector, AssetType.ImageBitmap, AssetType.Sound],
getAssetUrl);
If you're using ES6 you may be able to simplify all of the above quite a bit:
storage.addWebStore(
[AssetType.ImageVector, AssetType.ImageBitmap, AssetType.Sound],
asset => `https://assets.example.com/path/to/assets/${asset.assetId}.${asset.dataFormat}/get/`);
Once the storage module is aware of the sources you need, you can start loading assets:
storage.load(AssetType.Sound, soundId).then(function (soundAsset) {
});
If you'd like to use happycode-storage with happycode-vm you must "attach" the storage module to the VM:
vm.attachStorage(storage);
Testing
To run all tests:
npm test
To show test coverage:
npm run coverage
Committing
This project uses semantic release
to ensure version bumps follow semver so that projects using the config don't
break unexpectedly.
In order to automatically determine the type of version bump necessary, semantic
release expects commit messages to be formatted following
conventional-changelog.
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
subject and body are your familiar commit subject and body. footer is
where you would include BREAKING CHANGE and ISSUES FIXED sections if
applicable.
type is one of:
fix: A bug fix Causes a patch release (0.0.x)
feat: A new feature Causes a minor release (0.x.0)
docs: Documentation only changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance May or may not cause a minor release. It's not clear.
test: Adding missing tests or correcting existing tests
ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
chore: Other changes that don't modify src or test files
revert: Reverts a previous commit
Use the commitizen CLI to make commits
formatted in this way:
npm install -g commitizen
npm install
Now you're ready to make commits using git cz.
Breaking changes
If you're committing a change that makes an API change, or will
otherwise require changes to existing code, ensure your commit specifies a
breaking change. In your commit body, prefix the changes with "BREAKING CHANGE: "
This will cause a major version bump so downstream projects must choose to upgrade
and will not break the build unexpectedly.
Donate
We provide Happycode free of charge, and want to keep it that way! Please consider making a
donation to support our continued engineering, design, community,
and resource development efforts. Donations of any size are appreciated. Thank you!