Another small bug fix release, this one was more of a problem in application code using Holster, but investigating what went wrong there led to some improvements.
The app I'm working on requires a server account and if one doesn't exist when it starts it would create one in Holster. The problem is the user lookup timeout was too short, so it created a second account! This was not helpful since it provides a public key to the browser to look up account information... and now it's split across multiple accounts which isn't going to work.
The answer was to remove the account creation code from the app entirely. This meant I needed a new way to set up the server account in the first place, which led to a nice use of the Node REPL to configure it manually:
// Or switch to "@mblaney/holster/src/holster.js" in your own project.
const {default: Holster} = await import("./src/holster.js")
const holster = Holster()
const user = holster.user()
I've left out the actual commands, but from there you can use holster and user to query the API. Besides fixing my problem it also provides a nice way to interact with your data from the command line.
Holster 1.0.1
I had one annoying bug that I hadn't got to the bottom of before yesterday's 1.0 release. I even added a bunch of unit tests to make sure Holster was working as I expected. The previous versions of the unit tests looked like this:
test("get unknown keys in for loop callbacks null", (t, done) => {
for (let i = 0; i < 5; i++) {
holster.get("unknown" + i, data => {
assert.equal(data, null)
if (i === 4) done()
})
}
})
The idea is that you should be able to make as many requests as you like and Holster will manage the context of each request and map it to the right callback. Can you see the problem with the test though? The loop will finish before the callbacks are called, so the condition will match and done() will be called regardless of if the callbacks were each called correctly. In fact only one was being called but the tests still passed.
They now look like this:
test("get unknown keys in for loop callbacks null", (t, done) => {
let count = 0
for (let i = 0; i < 5; i++) {
holster.get("unknown" + i, data => {
assert.equal(data, null)
count++
})
}
setTimeout(() => {
if (count === 5) done()
}, 200)
})
Which makes sure each was called correctly. Holster wasn't able to pass this version of the test because the context id was being dropped. The id is passed to the API as a parameter that I thought would form part of the closure, but it seems the callback function itself is created before that can happen. The answer was to pass the id to a function that then returns a new callback, which then appears to be called correctly.
This was enough of a problem in the app I'm working on for a 1.0.1 bug fix release.
Holster 1.0.2
The app I'm working on requires a server account and if one doesn't exist when it starts it would create one in Holster. The problem is the user lookup timeout was too short, so it created a second account! This was not helpful since it provides a public key to the browser to look up account information... and now it's split across multiple accounts which isn't going to work.
The answer was to remove the account creation code from the app entirely. This meant I needed a new way to set up the server account in the first place, which led to a nice use of the Node REPL to configure it manually:
// Or switch to "@mblaney/holster/src/holster.js" in your own project. const {default: Holster} = await import("./src/holster.js") const holster = Holster() const user = holster.user()I've left out the actual commands, but from there you can use
holsteranduserto query the API. Besides fixing my problem it also provides a nice way to interact with your data from the command line.Holster 1.0.1
test("get unknown keys in for loop callbacks null", (t, done) => { for (let i = 0; i < 5; i++) { holster.get("unknown" + i, data => { assert.equal(data, null) if (i === 4) done() }) } })The idea is that you should be able to make as many requests as you like and Holster will manage the context of each request and map it to the right callback. Can you see the problem with the test though? The loop will finish before the callbacks are called, so the condition will match and
done()will be called regardless of if the callbacks were each called correctly. In fact only one was being called but the tests still passed.They now look like this:
test("get unknown keys in for loop callbacks null", (t, done) => { let count = 0 for (let i = 0; i < 5; i++) { holster.get("unknown" + i, data => { assert.equal(data, null) count++ }) } setTimeout(() => { if (count === 5) done() }, 200) })Which makes sure each was called correctly. Holster wasn't able to pass this version of the test because the context id was being dropped. The id is passed to the API as a parameter that I thought would form part of the closure, but it seems the callback function itself is created before that can happen. The answer was to pass the id to a function that then returns a new callback, which then appears to be called correctly.
This was enough of a problem in the app I'm working on for a 1.0.1 bug fix release.