You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I have been working on making a search index for npm modules that work with browserify. In order to do this, obviously, for each module on npm, I need to determine whether or not it works with browserify. Easy! I thought. I will run the browserify cli tool on the module browserify node_modules/that_module, and if it exits normally, it works with browserify. So I did that, and implemented a search engine on this premise. Except that, in the search results, I found a lot of modules which, although it "passed the test", they still were useless because simple the act of loading the bundle in a browser would result in a runtime error - a lot of these were a result of the module testing for process.versions.node which doesn't exist in the browserify process shim. Okay, I thought, I'll run the resulting bundle in jsdom, genious! That did reject lots of modules, but it still wasn't good enough. I still got a lot of modules in the search inde
I understand why and how this works, but it always catches me out. I wonder how obvious it is to others? Feel free to comment below.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
KeystoneJS provide Admin UI with one set of route controllers and view templates(list&item) for all of the models.But usually,you will need some custome views other than Admin UI to display models. Although the KeystoneJS documention don't tell us much about how to contruct custome view,we can learn this from the source code in skeleton project generated by yo keystone,or you can just check out the keystone demo project's source code.We will walk through the blog feature's implementation in this demo application to demonstrate how to construct custome UI in KeystoneJS application.
As KeystoneJS documention described in Routes & Views section,there is a routes/index.js file, where we bind application's URL patterns to the controllers that load and process data, and render the appropriate template.You can find following code in it:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters