Comments (21)
I would also need to access the app
instance either via the parameter injection or set by boot
to the factory/handler instance.
from loopback-boot.
Let's address the issue "one feature at a time". I think 2. Allowing the middleware to be optional is the most straightforward one, so let's give it the first shot.
So @bajtos what are the requirements for 2? Here is what I am assuming:
- If the middleware is not resolvable, don't
throw
and resume loading the rest of the middleware. Also, print theoptional
message to stdio. - If the middleware is resolvable, load it like other middleware.
Please confirm or correct.
from loopback-boot.
- If the middleware is not resolvable, don't
throw
and resume loading the rest of the middleware. Also, print theoptional
message to stdio.- If the middleware is resolvable, load it like other middleware.
@hacksparrow that's perfect 👍
Let's address the issue "one feature at a time".
+1 I'd add "one pull request per feature", but feel free to use whatever workflow that works best for you.
from loopback-boot.
@bajtos I have implemented a way to to pass app
as a parameter to middleware via middleware.json
. app
can be referenced as ${app}
.
middleware.json
"routes": {
"./middleware/hello": {
"params": ["${app}", {"app": "${app}"}]
}
}
How does the convention ${app}
look like to you?
from loopback-boot.
@bajtos also, for explorer to work seamlessly as a self-contained optional middleware, the middleware config should be the following, if I am not wrong:
{
"routes": {
"loopback-explorer": {
"optional": "Run `npm install loopback-explorer` to enable the LoopBack explorer.",
"params": ["${app}", {
"basePath": "${restApiRoot}"
}
]
}
}
from loopback-boot.
and of course, explorer has to take over the responsibility of doing what server/boot/explorer.js
is doing currently.
var restApiRoot = server.get('restApiRoot');
var explorerApp = explorer(server, { basePath: restApiRoot });
server.use('/explorer', explorerApp);
server.once('started', function() {
var baseUrl = server.get('url').replace(/\/$/, '');
console.log('Browse your REST API at %s%s', baseUrl, explorerApp.mountpath);
});
from loopback-boot.
@bajtos the implementation for parsing ${app}
, and its test is sitting on a branch on my fork - https://github.com/hacksparrow/loopback-boot/tree/feature/app-reference.
I'd like to open a PR for it, once the open PR for making middleware optional is merged.
from loopback-boot.
@hacksparrow I am afraid your proposal above goes against the original intention of this issue, which is to "Rework the explorer so that it can get the app object via req.app on the first request, in the same way as loopback.rest." I personally think it's a bad practice for middleware to expect the app
object in factory arguments, it should get the app it's mounted on via req.app
.
However, per the discussion in strongloop/loopback-component-explorer#21, I believe the agreed way forward is to rework loopback-explorer into a component. I'll take a close look on this tomorrow (CEST).
from loopback-boot.
Thanks for the feedback @bajtos, will change accordingly.
from loopback-boot.
@bajtos per this example:
{
"routes": {
"loopback#rest": {
"paths": ["${restApiRoot}"]
}
}
We will now call loopback.rest()
directly via a configuration in middleware.json
, instead of using server/boot/rest-api.js
, and therefore make the necessary changes to loopback/server/middleware/rest.js
to enable this, right?
from loopback-boot.
We will now call loopback.rest() directly via a configuration in middleware.json, instead of using server/boot/rest-api.js
Yes please.
therefore make the necessary changes to loopback/server/middleware/rest.js to enable this, right?
I am not aware of any changes that are necessary, could you please elaborate little bit more?
from loopback-boot.
therefore make the necessary changes to loopback/server/middleware/rest.js to enable this, right?
Did you mean implementing necessary changes to support "paths": ["${restApiRoot}"]
? That should be implemented in loopback-boot's lib/executor.js
from loopback-boot.
Thanks for the info @bajtos.
Another thing; what would be the interface for doing something like this?
var websitePath = require('path').resolve(__dirname, '../client');
app.use(loopback.static(websitePath));
from loopback-boot.
var websitePath = require('path').resolve(__dirname, '../client'); app.use(loopback.static(websitePath));
Assuming __dirname
is pointing to the same directory where server/middleware.json
is, then you can achieve the same result using the following entry in server/middleware.json
file:
{
"files": {
"loopback#static": {
"params": "$!../client"
}
}
}
from loopback-boot.
@bajtos opened a PR to declaratively load loopback.rest - #149. However, there is a bunch of build errors triggered by some pre-existing code, I can fix it if I get the go-ahead. Please review and let me know.
from loopback-boot.
Also, are we not supporting const
yet?
from loopback-boot.
@bajtos is there a reason why loopback#rest takes an array of paths while loopback-explorer takes a single mountPath
?
from loopback-boot.
@bajtos Can this be closed with the merging of #149?
If not, what are the remaining items to complete before this can be closed?
from loopback-boot.
@crandmck component-config.json
should parse ${var}
too. I have gotten it to parse, but still working on a way for explorer to be loaded declaratively and replicate its current behavior.
With explorer loading as intended, we can close this.
from loopback-boot.
@crandmck as @hacksparrow wrote, we need to land one more change to loopback-boot and then rework the example app to load the explorer component declaratively.
@hacksparrow don't worry about reproducing exactly same behaviour. The important part is to print the explorer URL on start. The support for explorer being an optional dependency can be dropped and explorer can become a proper (required) dependency.
from loopback-boot.
@bajtos @crandmck I guess we can close this now?
from loopback-boot.
Related Issues (20)
- Subfolders in boot folder HOT 7
- [forward-port] Fix resolution of middleware modules
- Boot scripts are loaded, but not actually run HOT 9
- organizing configuration files leads to problems HOT 3
- test failing on browserify due to form-data HOT 1
- Document refactored design of loopback-boot HOT 1
- datasources duplicated when booting using a config HOT 1
- models not loaded when using config on boot HOT 1
- 3.0.0
- Async boot scripts - silent failure with security risk HOT 6
- resolveAppScriptPath() is not pass scriptExtensions to fixFileExtensions() HOT 2
- [BUG] Middleware is loading .js.map of .js HOT 1
- The middleware "loopback#static" in phase "files"is not defined in the main config
- Async operations in component initialization HOT 3
- isomorphic and uglify causing "AssertionError: must provide a valid {{SharedClass}}" HOT 1
- custom middleware not found when boot options are just __dirname HOT 2
- Why next() requires to trigger process.nextTick in bootscript. HOT 2
- export-api-def doesn't work with loopback-boot@3 HOT 1
- Address usage of config/application on boot LBOptions HOT 2
- Loopback-boot updating to 3.3.1 producting "LoopBack server listening @ https://undefined:undefined/" HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from loopback-boot.