innet

innet

CANT inc. application build ecosystem.

Overview

innet is designed to simplify and standardize application development with a flexible and modern ecosystem.

It combines the best features from popular libraries and frameworks, offering a familiar yet uniquely powerful experience.

innet is a JavaScript ecosystem built around a single function-based core, offering an out-of-the-box solution for a variety of application types:

• API Server
• Website
• Browser plugin (planned)
• Native application (in work)

JSX Everywhere

innet comes with built-in support for JSX, providing a smooth developer experience for writing components.

You can use JSX not only on the client side but also on the server side.

Check out @innet/jsx for more details.

JSX works seamlessly on both client and server!

Modular Plugin Architecture

innet's functionality is split across modular plugins. Include only what you need:

• Frontend plugins: refs, portals, context, lifecycle, state management
• Server-side plugins: api, components, proxy, async, endpoints
• Shared plugins usable on both sides

You can use the same plugins on client and server!

Component-Based Approach

innet fully supports components as a powerful way to build reusable parts of your application.

Same components can be used on server and client!

Explore the many features below to get started!

Installation

Using npm:

npm i innet

Using yarn:

yarn add innet

Getting Started

You can start working with innet using @innet/dom for frontend apps, @innet/server for backend apps, or @innet/native for native mobile development.

The main innet function accepts two required parameters and two optional:

• The first parameter is the application description ("what" to do).
• The second is a handler defining "how" to execute the application.
• The third (optional) parameter sets the task priority, with a default value of 0.
• The fourth (optional) parameter determines the queue order, where LIFO is used if true; otherwise, FIFO by default.

Example usage:

import { innet } from 'innet'

import app from './app' // what to do
import handler from './handler' // how to do it

innet(app, handler)

The app can be any type, while the handler must be a Handler object. Create a handler using the createHandler function:

import { createHandler } from 'innet'

export default createHandler([])

By default, the handler does nothing until you add plugins to define functionality.

const sum = () => ([a, b]) => {
  console.log(a + b)
}
// sum is a plugin

const plugins = [
  sum,
]

const handler = createHandler(plugins)

innet([1, 2], handler) // Outputs: 3

Plugins

Plugins are functions that run during handler creation and return a HandlerPlugin.

Example: a logger plugin

import { HandlerPlugin, NEXT, useApp } from 'innet'

function logger(): HandlerPlugin {
  console.log('logger: initialization')

  return () => {
    console.log('logger: app', useApp())

    return NEXT
  }
}

HandlerPlugin functions have access to two hooks: useApp and useHandler.

Example of an async plugin to handle promises:

import { innet, HandlerPlugin, NEXT, useApp, useHandler } from 'innet'

function async(): HandlerPlugin {
  return () => {
    const app = useApp()

    if (!(app instanceof Promise)) return NEXT

    const handler = useHandler()

    app.then(data => innet(data, handler))
  }
}

Try using both plugins together:

const app = new Promise(resolve => resolve('test'))

const handler = createHandler([
  logger,
  async,
])
// > 'logger: initialisation'

innet(app, handler)
// > 'logger: app', Promise

await app
// > 'logger: app', 'test'

Plugin order matters:

const app = new Promise(resolve => resolve('test'))

const handler = createHandler([
  async, // change order
  logger,
])
// > 'logger: initialisation'

innet(app, handler)
// nothing happens

await app
// > 'logger: app', 'test'

Extending a Handler

You can extend handlers using createHandler by passing plugins and an existing handler to build on:

const handler1 = createHandler([
  async,
  sum,
])

const handler2 = createHandler([
  logger,
], handler1)

Task Priority

Control the execution priority of innet tasks with the third and the fourth optional arguments.

• The fourth argument, when true, switches the order of the queue from the default FIFO to LIFO.
• Lower priority values are executed before higher priority values.
• Tasks with the same priority are ordered based on FIFO or LIFO, depending on the fourth parameter.

import { queueNanotask } from 'queue-nano-task'

const handler = createHandler([logger])

queueNanotask(() => {
  innet('Mounted', handler, 2)
  innet('Mounting', handler, 1)
  innet('Rendering', handler, 0)
  innet('WillMount', handler, 1, true)
})
// log: ['Rendering', 'WillMount', 'Mounting', 'Mounted']

Explore more general plugins and utilities in @innet/utils

Issues & Contributions

If you find bugs or want to suggest features, please open an issue on GitHub.