mojolicious / mojo.js Goto Github PK

Hi, how to enable cors with mojo.js with just an function like cors() in express.js ?

await ctx.render({ view: 'deals/category', format: 'json'}, { deals }); the category.html.tmpl is being loaded instead of category.json.tmpl file.

I have plugin for database connection. Inside plugin i add stop application hook for closing database connection.

When run node index.js i get list of commands, but not exit to shell.
When run node index.js routes i get routes, but not exit to shell.

Commands start application, with plugins, but when command finished, does not stop application properly.
Need run application stop hook after command finished or command list printed.

Can we get a web socket live chat example with mojojs?

I'm not sure how to broadcast a message to all connected clients.

Here were will collect the most commonly requested 3rd party plugins that should be available as mojo-plugin-* modules on NPM. Everyone is invited to work on them and/or discuss their design on the Forum, on Matrix, or IRC. You can use mojo-plugin-ejs as a template.

• Express.js middleware adapter plugin
• OpenAPI plugin
• Nunjucks template engine (mojo-plugin-nunjucks)
• Minion job queue (work in progress: minion.js)
• Serverless adapter plugins (AWS: mojo-plugin-lambda)
• CORS (#95)

We will link to the plugins once they exist, there can be more than one per topic of course.

I have hook for prettify command names

  app.addAppHook('command:before', (app: MojoApp, _args: string[]) => {
    app.cli.commands = _.mapKeys(app.cli.commands, (_value, key) => key.replaceAll('_', ':'));
  });

but it's not work, because hook start before all command load

I noticed that the code incorrectly checks that the variable is an object. For example: _formData. The problem is that typeof null === 'object". Correct implementation: isObject

Count and store metrics for http/ws/pg/minion, like a total requests/request per sec/duration/query length.

I tried this but I get errors:

{
  "type": "module",
  "dependencies": {
    "@mojojs/core": "^1.5.1"
  },
  "devDependencies": {
    "tap": "^16.3.0"
  },
  "scripts": {
    "test": "tap --no-coverage test/*.js",
    "dev": "node ./index.js -l 'http://*:8080",
    "start": "MOJO_REVERSE_PROXY=1 node ./index.js daemon -l 'http://*:8080'"
  }
}

I'm using an nginx proxy in prod but not dev

This is almost the very same syntax that Koa.js has, you may consider merging the project or using it and its ecosystem as a reference implementation

router.get('/path/:x', async (ctx, next) => {
  console.log(ctx.params.x);
  await next;
});

See also,

• https://koajs.com/
• https://github.com/koajs/
• https://www.npmjs.com/package/koa-router

Thanks for reply ^_^

Feathers.js is its own client which is useful to not only standardize web socket communication, but provide helpers for synchronizing data between client and server. Is this something planned for mojo.js, or already possible, or not happening?

https://docs.feathersjs.com/api/client.html

In this issue i will keep a list of features missing for mojo.js 1.0. The list will change regularly. Volunteers are welcome to propose an implementation. We do not port features directly from Mojolicious, they also have to use JavaScript best practices. It's best to discuss ideas on IRC (#mojo.js on Libera.Chat), so you don't end up wasting your time.

• TypeScript
  • Port everything (one module at a time is fine)
• Cookies:
  • Client/Server cookie encoding/decoding module
  • CookieJar for client
  • Signed cookies for the server
  • Sessions for the server
• Forms (application/x-www-form-urlencoded):
  • Support client.post('/foo', {form: {a: 'b'}}) in the client
  • Support await ctx.req.form in the server
• Forms (multipart/form-data):
  • Client/server multipart encoding/decoding module (maybe 3rd party?)
  • Design API for the client (client.post('...', {formData: ...}), form values and file uploads)
  • Design API for the server (await ctx.res.formData(), form values and file uploads)
• Static:
  • Last-Modified/If-Modified-Since/Etag support
  • Accept-Ranges support
  • Design API for sending a static file from an action instead of rendering
• Test:
  • WebSocket methods (websocketOk, sendOk, messageOk, messageOk, finishOk)
  • Make app.newMockContext().someHelper() work
  • Full test coverage
• Content negotiation
  • respondTo method
• General HTTP tools
  • redirectTo (options for status and maybe some future proofing would be nice)
  • urlFor method
• Renderer
  • renderMaybe method
  • renderToString method
  • Layouts for ejs (maybe as part of the plugin, or maybe as a renderer feature)
  • Include for ejs (maybe with renderToString, or native ejs include)
  • gzip compression
• Commands:
  • routes command
  • get command (already exists, but needs more HTTP features)
  • gen-lite-app, gen-full-app, gen-plugin (once we have settled on a structure)
• Built-in templates
  • Not found (can be ported directly from Mojolicious)
  • Exception (can be ported directly from Mojolicious)
  • Support for custom not found and exception templates
  • Code preview on development exception page
• Config plugin
  • JSON config (no template for starters, but with support for mode specific files)
• Server
  • MOJO_SERVER_DEBUG=1 from Mojolicious (without performance loss if not used)
  • HTTPS support
  • Reverse proxy support (X-Forwarded-For, X-Forwarded-Proto)
• Client
  • Option to follow a certain number of redirects
  • Basic authentication
  • CONNECT and SOCKS proxy support (probably via custom agents like https-proxy-agent and socks-proxy-agent)
  • HTTPS support (with insecure option for self signed certs)
  • gzip compression
• Condition support
  • Design API on router layer (performance is important)
  • Header conditions default pluginversion)
• Hook support
  • Design API (expected to be completely different than the Perl version, maybe events on app object)
• Docs
  • Tutorial giving a basic overview of the framework, similar to the Mojolicious tutorial (Markdown)

All features will need full test coverage. And make sure that there are no performance regressions. An easy test is:

$ node examples/hello.js server
...
$ wrk -c 100 -d 10s http://127.0.0.1:3000
...

• Trying to run Schema validation example in docs, but always get invalid results when testing with
  <GET /form?test=13> or any other number.
• The reason is that ajv is always getting a string value assigned to any query variable ("test" in this case), so when it checks against an expected 'number' type it never succeds. This happens on param variables, as there is no way to specify a number (or a boolean) type inside the url.
• ajv can coerce input data to be the expected type when it makes sense. That would solve the issue, and also some "common sense" cases when body data received was expected to be type 'number', but a string is received (this is similar to the case on the example above, except that you could always send any type of data inside a json formatted body, at least if you can control that requesting app).
• I will be preparing a PR based on last point for your consideration in a few minutes.

As both mojo.js and Deno are young projects that have great potential and are (imo) great match, would it be possible to port mojo.js to Deno ecosystem?

Hello,

Just wanted to announce that I've published a new module to run mojojs applications inside AWS Lambda.
https://www.npmjs.com/package/mojo-plugin-lambda
It's rough and very basic, but it works for me and a very small application that I've written. Hope it helps others embrace mojojs.

Thanks for mojojs and the brilliant documentation, clear code, examples, and complete documentation (which has been a big help for getting this working (I haven't written JS for over a decade).

Right now TypeScript support is decent, but there's still a few rough edges. In this issue we can collect problems with types and possible solutions.

Known Issues:

• Built-in helpers like ctx.exception are not declared on the MojoContext type
• We have no best practice yet for 3rd party plugins to declare the helpers they add to MojoContext
• TypeScript example plugin, easy to fork (mojo-plugin-nunjucks)

Add default routes and controllers for /startup, /liveness, /readiness. And some top level functions for control liveness/readiness state (ex app.liveness(true), app.readiness(false)).

Demo application

/*
 * Application demonstrating the various HTTP response variants for debugging
 */
import mojo from '../lib/core.js';
import net from 'net';

const app = mojo();

app.get('/res1', ctx => {
  const client = net.createConnection({port: 8124}, () => {
    console.log('connected to server!');
  });

  return ctx.render({text: 'Hello World!'});
});

app.get('/res2', async ctx => {
  function myAsyncFunction() {
    return new Promise((resolve, reject) => {
      const client = net.createConnection({port: 8124}, () => {
        console.log('connected to server!');
        resolve(client);
      });
      client.on('error', error => {
        reject(error);
      });
    });
  }

  await myAsyncFunction();

  await ctx.render({text: 'Hello World!'});
});

app.start();

run stop hook after command finished or print list command.

The text of the logo appears almost black-on-black in dark mode.

Modern HTML makes it pretty easy to specify an alternate dark-mode image:
https://dev.to/dailydevtips1/light-and-dark-mode-image-in-html-lji

With the 1.0 release quickly approaching done, it is time to make a list of features we would like to see afterwards.

• Core framework
  • Application mount support (app.plugin(mountPlugin, {app: fooApp, path: '/prefix'}))
  • Nested helpers (ctx.foo.bar(...))
  • Custom URL class with better manipulation methods (like Mojo::URL)
  • Express middleware support (maybe as a plugin with request and response object emulation)
  • Proxy helpers (ctx.proxyGet(), ctx.proxyRequest())
• Assets
  • URL generation (ctx.urlForAsset('foo.js') returns /static/assets/foo.abcd1234.js)
  • Headers to prevent caching for assets in development mode (foo.development.js)
• Documentation
  • Port testing guide to JavaScript
  • Port all reference documentation examples to JavaScript
  • Form validation with JSON schema
  • Many more recipes for the cookbook (including all from Mojolicious)
  • Reference documentation for classes (needs to be generated on the website)
• WebSockets
  • Support for custom headers in handshake (client and server)
  • Support for subprotocol negotiation from action
  • Reconnect feature for the client
• Client
  • Switch to @mojojs/user-agent (more WHATWG APIs)
  • UNIX domain sockets (http+unix://...)
  • HTTP/2 support (we might just support it via the fetch API)
  • HTTP/3 support (:no_entry_sign: not yet in Node.js)
• Server:
  • UNIX domain sockets (http+unix://...)
  • HTTP/2 support (:warning: tricky because of WebSockets)
  • HTTP/3 support (:no_entry_sign: not yet in Node.js)
  • Server-Sent Events (provide an actual API)
• Renderer
  • Port all the tag helpers
    • colorFieldTag
    • dateFieldTag
    • datetimeFieldTag
    • emailFieldTag
    • fileFieldTag
    • hiddenFieldTag
    • labelFor
    • monthFieldTag
    • numberFieldTag
    • passwordFieldTag
    • rangeFieldTag
    • searchFieldTag
    • selectFieldTag (⚠️ quite complex)
    • telFieldTag
    • textFieldTag
    • timeFieldTag
    • urlFieldTag
    • weekFieldTag
• Example apps
  • Chat (ported from Perl)
• TypeScript
  • Updated app generator commands with TypeScript support
  • Update plugin generator command with TypeScript support (--ts flag)
• Command line
  • perl -Mojo -E '...' equivalent (something better than npx mojo eval -v '...'?)