hoodiehq / hoodie Goto Github PK
View Code? Open in Web Editor NEW:dog: The Offline First JavaScript Backend
License: Apache License 2.0
:dog: The Offline First JavaScript Backend
License: Apache License 2.0
things like .on('authenticated')
don't show up on http://hood.ie/ or in the hoodie.js readme right now
also, make sure that hoodie.share.open passes correct options.prefix to hoodie.open
$type
should become type
, $createdAt
simply createdAt
. I thought it would be a good idea to mark these properties as "system propreties". But that's tech-centric. And we are user-centric. And when working on hoodie apps, I find the $ prefixes for these properties rather confusing, as I want to use them in my apps.
At the moment, every new user that signs up gets automatically confirmed. To enable confirmation emails, we need a method to confirm an account with a token that gets send via email, e.g.
to activate your account, please click the following link:
http://www.myapp.com/#/activate/hash123
In my App, I'd read out "hash123" and then run hoodie.account.confirm( token )
Question now is: how could the CouchDB Magic work?
reproduce: in the default app - decline to fill in the 2nd password field, account will be created anyway
To fix it, hoodie.store should bootstrap all data initially
Currently, the following code will only add 'shareId' to the objects $shares
has:
fix hoodie.store.find('task', '123').shareAt('shareId')
So it works fine if 'shareId' is a share that I created my self. But it won't work if it belongs to a share that I've not created but want to contribute to.
To fix this, the shareAt
method needs to create a new share if it doesn't exist yet. Problems to think of:
My idea: make shareAt
always create a new share if it's not in my local store yet. Set $createdBy
to 'share/shareId'. Make the share worker handle the validation:
$error
property to the appropriate error. the local hoodie.share
needs to listen to errors and act accordinglyHere's a list of current modules we have
Core:
// core
hoodie.my.store
hoodie.my.config
hoodie.my.account
hoodie.my.remote
//extensions
hoodie.user
hoodie.share
hoodie.global
hoodie.email
Why not kick the .my
and go with the following?
// core
hoodie.store
hoodie.config
hoodie.account
hoodie.remote
//extensions
hoodie.user
hoodie.share
hoodie.global
hoodie.email
If I remember it correctly, we introduced the .my
prefix to make it clear that all the modules are me-centred. But no I think: they all are me centered, so why not simply kick it? Backend is where we have to handle multiple users, but in the frontend, there is always only one user who's logged in, isn't it?
... 'cause docs is to couch-y and we call it object everywhere else
Anything else?
we want to have a lastActiveAt timestamp for users.
Current idea would be to update my _users doc each minute with a new lastActiveAt timestamp.
That would produce tons of revisions in the _users docs, not sure if that's feasible
follow up for #44
when I change an object and signout within the 2 second timeout of store:idle
, local changes get pushed to remote, which leads to a 401 error.
A push should not happen if the connection to remote has been disconnected
when I have a hoodie.account.on('authenticated'
listener it calls the callback 3 times when I do hoodie.account.authenticate
can I do this?
var hoodie = require('hoodie')
my dev workflow is here: https://gist.github.com/maxogden/5147486
i'm basically trying to figure out how to split my hoodie app up into many node modules and use beefy
as the dev server, rather than the built in hoodie start
when a user account is destroyed (in the default app), re-use of the username causes a db conflict
as described in the public store wish list API
is the only difference between store.add
and store.save
that you can specify an id with save?
I followed the installation instructions and started a project with "hoodie new". I cd'd into the directory and tried "hoodie start". Here's the terminal output.
I confirmed local-tld is running re: http://twitter.com/hoodiehq/status/321415285519298560
I'm really excited about the project, so I hope you can help me out. 👍
from working with hoodie on some apps, I find it rather confusing to have a Remote instance which comes with methods to interact with the remote database, and then some more which are namespaced by store.
e.g. hoodie.remote.pull()
vs. hoodie.remote.store.findAll()
I think we should merge these two modules and get rid of the .store
namespaced methods
user logins/logouts in the default app do not refresh the browser contents using the Safari browser under 10.6.8.
one has to do a manual reload to see that state has changed.
hiya, this code doesn't return any documents:
hoodie.account.on('signin', function() {
hoodie.store.findAll('email').done(function (objects) { console.log(objects) })
})
hoodie.account.signIn('test', 'test')
but if I wait a second and then run hoodie.store.findAll('email').done(function (objects) { console.log(objects) })
again then all the documents show up
STRs:
the set of tasks that will have been saved can be a subset of the set of tasks entered. Somehow, the app needs to "persist to disk" before signing out. Filing here rather than in demo app as I expect there's a bigger architectural discussion to have about how to make that happen.
hoodie.js is currently using LocalStorage for local persistence. It's slow, synchronous, and several people advised me not to use it for anything beyond a cookie functionality.
On the other side, there is http://pouchdb.com/. It works with indexdDB, but there is also a webSQL adapter. What kept me from using PouchDB is the lack of support for IE < 10.
But, I just found out that the most simple fallback is to use PouchDB, is to use it directly with the CouchDB endpoint. So when a user saves a document, the update gets directly sent to the Couch, instead of storing all documents locally in the browser and then asynchronously replicate with the Couch in the backend.
Also, when thinking about browser support for hoodie: IE < 9 does not support CORS, which is a requirement for the current default setup of a hoodie app.
It's definitely something we should consider.
hoodie.js currently depends on jQuery for pragmatic reasons. It mainly uses jQuery's ajax and promise implementations.
"created" --> "create"
"destoryed" --> "destroy"
etc .
We just discussed it with @janl, @espy and @colegillespie
other opinions?
MacBook-Air-2:~ rrichrs$ brew tap hoodiehq/homebrew-hoodie
Cloning into '/usr/local/Library/Taps/hoodiehq-hoodie'...
error: The requested URL returned error: 403 while accessing https://github.com/hoodiehq/homebrew-hoodie/info/refs
fatal: HTTP request failed
Ryans-MacBook-Air-2:~ rrichrs$
We currently depend on jQuery for promises. Time to move on.
https://github.com/cujojs/when
created_at
--> createdAt
changed_docs
--> changedDocs
etc
We want to follow the ECMA Script conventions
remote.on() returns the object id as a string instead of the entire object.
Example:
hoodie.remote.on('changed', function(type, id, changedObject){
console.log("Woo: ",changedObject)
});
// -> Woo: ag0qdhr
Calling sign_up() while a user is already logged in returns a 404 and throws an error.
Expected behavior would be to sign out the current user and then seamlessly sign up the new one.
it would be cool to have hoodie.extend to accept URLs of JavaScript files that can be loaded asynchronously, like
hoodie.extend('http://debug.hood.ie/script.js').then( function() {
hoodie.debug.showLocalStore()
})
Looking over the code, I'm not 100% sure what's happening if app.store.update( type, id, {nr: 1} )
is executed but the same type and id was changed in the mean time on the server.
Is the object on the backend always overwritten with the latest object send by using the app.store.update
api? Does the backend do some merging on the way? Is there a way to detect there is a conflict (e.g. does app.store.update
fail?) and what's the best way to resolve it again?
(I think you gave me some of these answers this afternoon, but I'm not 100% sure anymore and some documentation would be helpful in general I guess.)
tl;dr
This is a great opportunity to set the cornerstones of the future hoodie.js, your chance to become core contributor. The only requirement is to remain the frontend API.
Leave a comment if you're interested.
hoodie.js is currently written in CoffeeScript. The reason is, that I'm very comfortable myself to write CoffeeScript that documents itself pretty well. And at some points, when the code would become too complex, I'd rather keep it simple, readable, but therefore less performant.
I think that there can live multiple implementations of hoodie.js among each other, even for the same backend. There are other libraries that have that, like underscore.js or mustache.js.
But the main implementation of hoodie.js should be in pure JavaScript, I'd still keep the CoffeeScript implementation as learning code for the people that like it.
This is a huge chunk of work. But it's also a great opportunity to gather several developers that want to reimplement hoodie.js in pure JavaScript, and compine their experience to make it super solid. And the coolest thing: the specs are already there!
Comment if you're interested to help building it.
When starting the hoodie app just created using ‘hoodie new’, all HTTP requests to api.appname.dev return:
An error has occurred: {"code":"ECONNREFUSED","errno":"ECONNREFUSED","syscall":"connect"}
After entering an admin password passoword, hoodie crashes because the connection was refused with an invalid JSON response (starting with A).
Below is hoodie’s log.
$ hoodie start
> [email protected] start /Users/sander/Code/appname
> node node_modules/hoodie-app/lib/hoodie-app.js
Start local couch on port: 6004
CouchDB Started
hoodie server started on port '6003'
[api req] GET /
[api req] GET /
[api req] GET /
Please set an admin password: test[api req] GET /
[api req] GET /
undefined
setup done
open http://appname.dev in your browser
starting: 'worker-users'
initializing appname worker with:
{ server: 'http://couch.appname.dev:80',
admin: { user: 'admin', pass: 'test' },
persistent_since_storage: false,
name: 'users' }
[users] [Setup] reading global config from modules/module/appconfig …
All workers started.
Your App is ready now.
[static req] GET /
[users] [Setup] reading user config from modules/module/users …
[users] SyntaxError: Unexpected token A 0 [ 'SyntaxError: Unexpected token A',
' at Object.parse (native)',
' at Request.db_response [as _callback] (/Users/sander/Code/appname/node_modules/hoodie-worker-users/node_modules/hoodie-worker/node_modules/cradle/node_modules/follow/lib/feed.js:121:17)',
' at Request.request.self.callback (/Users/sander/Code/appname/node_modules/hoodie-worker-users/node_modules/hoodie-worker/node_modules/cradle/node_modules/follow/node_modules/request/main.js:104:22)',
The couch.stderr file contains a couple of lines like this:
execvp(): No such file or directory
I built CouchDB using homebrew, but installed Node.js using the Mac installer. Could that be the reason it fails (e.g. CouchDB not being able to find node)?
When hoodie.account.signUp
or hoodie.account.anonymousSignUp
because the account does not get resolved and the user reloads the page, hoodie should automatically try to finish the signUp.
Making sending emails from the client is great, but it also makes it easier for spammers to abuse the functionality.
I don't know how this is prevented in normal business applications. Here some ideas of mine:
The idea of email-types look handy to me to have some generic mechanism to define the emails send during the welcome, confirm and password-lost process.
they are all related to the Hoodie.Account module
authenticate
should not return false if username
is not set. There arewindow.setTimeout @authenticate
in constructorhoodie.my.config.get('account.username')
is a different email addressI'm not sure whether this is the correct sequence when starting hoodie app. I got the issue below, it asked to create a new "admin" password, then follow by an exception:
$ hoodie start
[email protected] start /Users/tslsf/project/hoodie/mynewapptest
node node_modules/hoodie-app/lib/hoodie-app.jsStart local couch on port: 6004
CouchDB Started
hoodie server started on port '6003'
Please set an admin password: admin
undefined
setup doneopen http://mynewapptest.dev in your browser
starting: 'worker-users'
initializing mynewapptest worker with:
{ server: 'http://couch.mynewapptest.dev:80',
admin: { user: 'admin', pass: 'admin' },
persistent_since_storage: false,
name: 'users' }
[users] [Setup] reading global config from modules/module/appconfig …
All workers started.
Your App is ready now.
CouchDB stop triggered by exitTypeError: Cannot read property '_id' of undefined
at new Response (/Users/tslsf/project/hoodie/mynewapptest/node_modules/hoodie-worker-users/node_modules/hoodie-worker/node_modules/cradle/lib/cradle/response.js:13:14)
at Request._onResponse as _callback
at Request.self.callback (/Users/tslsf/project/hoodie/mynewapptest/node_modules/hoodie-worker-users/node_modules/hoodie-worker/node_modules/cradle/node_modules/request/index.js:142:22)
at Request.EventEmitter.emit (events.js:98:17)
at Request. (/Users/tslsf/project/hoodie/mynewapptest/node_modules/hoodie-worker-users/node_modules/hoodie-worker/node_modules/cradle/node_modules/request/index.js:856:14)
at Request.EventEmitter.emit (events.js:117:20)
at IncomingMessage. (/Users/tslsf/project/hoodie/mynewapptest/node_modules/hoodie-worker-users/node_modules/hoodienpm ERR! [email protected] start:node node_modules/hoodie-app/lib/hoodie-app.js
little brother of https://github.com/hoodiehq/worker-shares/issues/10
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.