StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
12125720
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2012-08-25T21:15:50.970
FavoriteCount
0
LastActivityDate
2012-08-25T21:15:50.970
LastEditDate
LastEditorUserId
0
OwnerUserId
785161
ParentId
11835096
PostTypeId
2
Score
27
ViewCount
0
LastEditorDisplayName
text
Body
TL;DR: Use <code>readdirSync()</code> instead of <code>readdir()</code> if you're just planning to read local files at startup time. If you're planning to actually read data from remote database or do any I/O at runtime, use your option #2 - the callback. Explanation and code examples below. Detailed explanation: While at first this might seem like a module/dependecy/require-related question, it's really not. It's a generic question of how to handle asynchronous code. Let me explain: <code>require()</code> is basically the only synchronous function widely used throughout node that deals with I/O (it requires other modules from filesystem). Synchronous means it actually returns it's data as return value, instead of calling a callback. The most basic 101 rule in asynchronous programming is: <blockquote> You can never take an asynchronous piece of code and create a synchronous API for it. </blockquote> <code>require</code> uses a special synchronous version of <code>readFile</code> called <code>readFileSync</code>. Since modules are really only loaded at the start of the program, the fact that it blocks the node.js execution while it's reading the module is not a problem. In your example however, you try to perform additional asynchronous I/O - <code>readdir()</code> done during the require stage. Thus, you either need to use synchronous version of this command or the API needs to change... So there's the background to your problem. You identified the two basic options: <ol> <li>using a promise (which is essentially the same as your <code>EventEmitter</code> example)</li> <li>using a callback (your second example shows this well) and a third is:</li> <li>using a synchronous version of the <code>readdir()</code> command called <code>readdirSync()</code></li> </ol> I would use the option #3 for simplicity reason - but only if you're planning to just read a couple files at startup time as your example implies. If later your DB module is actually going to connect to a database - or if you're planning to do any of this at runtime, jump the boat now and go with async API. Not many people remember this anymore, but promises were actually the original default of how to handle async in node.js. In node 0.1.30 however promisses were <a href="https://github.com/joyent/node/commit/bb0d1e">removed and replaced</a> by a standardized callback with the <code>function(err, result)</code> signature. This was done largely for simplicity reasons. These days, vast majority of your async calls takes this standard callback as the last parameter. Your database driver does it, your web framework does it - it's everywhere. You should stay with the prevalent design and use it too. <blockquote> The only reason to prefer promises or events is if you have multiple different results that can happen. For example a socket can be opened, receive data, be closed, flushed etc. </blockquote> This is not your case. Your module always does the same (reads some files). So option #2 it is (unless you can stay synchronous). Finally, here are the two winning options rewritten slightly: Synchronous option: good just for local filesystem at startup time <pre><code>// db.js var fs = require('fs'); exports = fs.readdirSync('.'); // main.js var db = require('./db'); // insert rest of your main.js code here </code></pre> Asynchronous option: for when you want to use DBs etc. <pre><code>// db.js var fs = require('fs'), cached_files; exports.init = function(callback) { if (cached_files) { callback(null, cached_files); } else { fs.readdir('.', function(err, files) { if (!err) { cached_files = files; } callback(err, files); }); } }; // main.js require('./db').init(function(err, files) { // insert rest of your main.js code here }); </code></pre>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POAsynchronous initialization of Node.js module
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USzzen
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POAsynchronous initialization of Node.js module
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTBountyClose
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COPromises don't help you with "multiple different results". Promises help you synchronize both errors and proper results when you have multiple asynchronous results that something else needs to use the results of. So I would edit the promises part out of that quote, because its not correct
 singulars
 PostPostId
 PO
 UserUserId
 USB T

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.