Cycle as attribute:

the given value is transformed to the corresponding type, be it String, Number, Boolean, Array or Object, once transformed it is sent to the cycle as property.

Cycle as property:

evaluates if the value is of the declared type:

• If it corresponds to the type:

  1. It is saved in props.

  2. An event is emitted (if this has been configured in the prop).

  3. It is reflected as an attribute (if this has been configured in the prop).

  4. It is sent to the update queue and subsequent rendering.

• It does not correspond to the type: an error is created by console with the following data:

  • target: Instance of the webcomponent.

  • value: Input value.

Many teams decide to use Atomico for the development of their design systems thanks to its similarity with React, which greatly facilitates the incorporation of human talent into the development of design systems.

Why use Atomico to create design systems?

1. Atomico offers you Storybook 7 Support with superpowers, thanks to @atomico/storybook you can create stories without the need to declare the argTypes or args since @Atomico/storybook creates them for you

2. @atomico/vite makes it easy for you to build in NPM-friendly ESM format

3. makes it easy for you to export your code by automatically adding the metadata so that it is optimally consumed as a package, @atomico/exports can even automatically create wrappers for React, Preact and Vue

4. makes it easy for you to maintain a token system efficiently and sustainably

We thank IBM IX since they have shared their experience in the development of the design system for their client Barmer, you can follow this case through Discord or Github.

Creating sites with Atomico is really easy and SEO friendly because:

1. With Atomico you can perform SSR and SSG thanks to tools like Astro build, with Astro + Atomico you can send previously rendered components to the client, thus giving a result at the HTML level that is really friendly with search engines.

2. Atomico being really small (3kB) your sites will load fast, especially if you only apply SSG with Atomico.

3. Atomico not only supports SSR through Astro, you can SSR today with Atomico in Next.js, Express or any environment that supports ESM modules.

4. (Coming soon) Yes, with Atomico soon you will be able to create blocks for Gutenberg easily

We recommend the use of build with the @atomico/astro plugin, with this you can create sites like

Preferably we recommend + React + Atomico, but in case your project inherits the use of Next.js you can do SSR with Atomico in Next.js using .

Syntax

const refHost = useHost();

Returns the instance of the webcomponent in reference format, this reference allows to extend behaviors when creating customHooks.

Example

import { useHost, useEffect } from "atomico";

function useListener(type: string, callback: (ev: Event) => void) {
  const ref = useHost();
  useEffect(() => {
    const { current } = ref;
    current.addEventListener(type, callback);
    return () => current.removeEventListener(type, callback);
  }, []);
}

From the example we can highlight that useListener is a customHook that allows listening to an event from the webcomponent without the need to link said event to the VirtualDOM.

Special properties

By default, the render is configured to be used within the webcomponent by reading the return of the function, but it can be used outside of Atomico, example:

This technique allows you to use any registered custom element without the need to know its tag-name for its use, example:

Advantage :

1. Remove leverage from tag-name

2. Infer the types of the props and autocomplete only if you use JSX and Atomico.

Atomico allows the use of the DOM, for this it establishes its created or recovered node as a constructor, example:

Atomico associates the variable associated with the instance as a constructor, example:

allows to declare a node within the scope of the function as static, this will optimize the diff process between render, achieving better performance in cases of high stress of the UI, example:

the biggest advantage of this is that the node accesses the scope of the webcomponent

Allows to clone a node from the virtualDOM, example:

The objective of this feature is to retrieve slot and use it as a template from the webcomponent.

Atomico allows reusing existing DOM in the document. This is done during the webcomponent instatiation, by setting a special property in the tag to mark it for hydration.

This can be done for shadowDom too:

Where:

• dispatchEvent: callback, dispatches the event from the webcomponent and allows defining the detail by receiving a first parameter

• myEvent: string, name of the event to dispatch.

It is normal that the state of your component depends on the references of a slot, this hook facilitates the process of observing these references without the need to associate the changes to a state.

Syntax

const update = useUpdate();

Where:

1. update: Callback, force component update.

useId is a Atomico Hook for generating unique IDs that can be passed to accessibility attributes.

Syntax

import { useId } from "atomico";

const stringId = useId();

Example

Use ID generate a unique ID for each component, this id can be useful for referencing CSS selectors or creating names for inputs that only the component knows about.

function component() {
  const id = useId();
  return <host id={id}>
    <style>{`#${id}{ display: block; color: white; }`}</style>
    <h1>useId</h1>
  </host>;
}

useProp allows you to work with a prop(property) of the webcomponent in a similar way to useState.

Syntax

const [value, setValue] = useProp(myProp);

Where :

• value: Current value of the prop.

• setValue: Callback to update the value of the prop.

• myProp: string, defines the name of the prop to be used by the hook.

Where:

1. useCounter is a customHook and that it can work with any property of the webcomponent of type Number.

2. useCounter returns 2 methods increment and decrement that modify the value of the prop.

3. useCounter can be instantiated multiple times for different properties.

Syntax

const memoValue = useMemo(callback, optionalArgumentList);

Where :

1. memoValue : Return memorized by useMemo.

2. callback: Function that is executed one or more times according to optionalArgumentList.

3. optionalArgumentList: Array of arguments that controls the execution of callback, if an argument of optionalArgumentList changes it will trigger that callback is executed again.

Hook that allows you to memorize a callback so that it keeps its scope

Where:

1. memoCallback : Return memorized by useCallback.

Syntax

useEffect(effectCallback, optionalArgumentList);

Where :

1. effectCallback : Function that is executed one or more times according to optionalArgumentList,effectCallback can return a function that will be executed only if effectCallback is executed again or the webcomponent is unmounted.

2. optionalArgumentList: Array of arguments that controls the execution of effectCallback, if an argument ofoptionalArgumentList changes it will trigger that effectCallback is executed again without first cleaning the effects subscribed by the previous execution.

useLayoutEffect replicates the logic of useEffect but with synchronous execution after rendering.

useLayoutEffect replicates the logic of useEffect but with synchronous execution before rendering.

With the new contexts API you will be able to easily communicate components without the need to handle events, by default the communication is top down, but through it you can share anything as long as it is defined as an object.

Atomico's api is similar to React's Context api, let's explore the behavior of Atomico's context api:

create a custom Element as a context, this will serve to synchronize all the components nested within it, you must always remember to declare the tagname of this customElement, example

It allows to consume the return of createContext, let's go back to the previous example and suppose that we want to consume the customElement Theme created by createContext, the code for this would be the following:

In this way useContext captures the value of the parent component or reuses the value given by default to createContext.

The idea is to create an instance of AbortController every time the hook's parameters change. Each parameter change will abort the previously generated controller, thus cancelling any subscribed promises.

The significant advantage of using useAbortController is the automatic cancellation of asynchronous processes that depend on it when modifying the arguments provided to useAbortController (similar to useEffect).

The purpose of this hook is to facilitate the consumption of promises.

where:

• callback : asynchronous function.

• args

with a similar approach to React's use hook, but with scope approach.

scope approach? yes, this hook seeks to resolve a promise from a callback return, this allows you to regenerate the promise according to the scope, example:

where:

This hook enables you to take control of the context from the component that instantiates useProvider, thus avoiding the need to instantiate the context node in the DOM.

Avoid creating an instantiable context node in the DOM.

We recommend the tool, if your project was created with the command npm init @atomico the test environment will be preconfigured, you can see this pre-configuration at .

To scale the test environment you can complement with tools such as:

1. : allows you to automate interactions and evaluate interactions of your interface.

Atomico makes it easy to declare events at the type level using the Host type.

Example

import { Host, c, useEvent } from "atomico";

type CustomDetail = { timestamp: number };

const MyComponent = c(
  (): Host<{ onMyCustomEvent: CustomEvent<CustomDetail> }> => {
    const dispatch = useEvent<CustomDetail>("MyCustomEvent");
    return (
      <host>
        <button
          onclick={() => {
            dispatch({ timestamp: Date.now() });
          }}
        >Click</button>
      </host>
    );
  }
);

In the previous code, we have declared the onMyCustomEvent event at the type level. According to the template logic, this event will be dispatched every time the button is clicked, and the detail attached to this event will be of type CustomDetail.

Atomico's render cycle works like this:

First, when the component is instantiated, 3 promises will be created pending resolution:

1. componentInstance.mounted: resolved once the connectedCallback has been executed by the customElement.

2. componentInstance.updated: the render cycle for first mount or update is encapsulated in componentInstance.updated.

3. componentInstance.unmounted: resolved once the disconnectedCallback has been executed by the customElement.

Render or rerender cases are:

1. First render.

2. Updating a property or attribute.

3. Update dispatched by a hook

Remember all updates are stacked into a single big loop of componentInstance.updated.

This improves the testing experience since to observe the changes you only have to wait for the resolution of componentInstance.updated , example:

The first rendering as the update of a prop will call to execute again the function that defines our component, Atomico internally stores the references to support the Hooks api and will render the virtualDOM returned by said function, this is encapsulated within componentInstance.updated

Atomico allows modifying its life cycle in cases of SSR, improving the rendering of the CSS in case of SSR and avoiding the effects of useEffect and useLayoutEffect

Technique to reuse the DOM generated by the SSR, Atomico only in the first render of the component that declares date-hydrate will retrieve the existing DOM in the DOM not created by Atomico to relate it to the virtualDOM, avoiding creating the node again.

Atomico by default has a good performance, but it can be further optimized if certain techniques are applied.

A static node is equivalent to using node.cloneNode(true)

The renderOnce property renders the node only once, one of the advantages of this technique is that the virtualDOM can access the scope of the function.

1. Its name cannot have the on prefix since, if it does, Atomico will recognize it as a property expecting to listen to the event.

2. It can only have one listener, limiting others from observing the event.

Atomico allows the definition of methods from the host tag, this in order to share the scope with the methods (Functions) of the component, but this escapes the definition of types, to patch this we must use the Host type, this will allow us to validate the method from the JSX, TSX and the component instance.

Host to method declaration

import {Host} from "atomico";

type MyMethod = (value: number)=>void;

function component():Host<{myMethod: MyMethod }>{
    const myMethod: MyMethod = ()=>{}
    return <host myMethod={myMethod }/>
}

If you develop with React, you will know 80% Atomico ... now why use Atomico?:

1. Atomico will not limit your React learning curve, what you learned in Atomico is applicable in React, for example hooks and virtualDOM.

2. Atomico is 3kB in size which is 7% of React + React-dom.

3. Better component abstraction, for example the use of the ShadowDOM will avoid the need to use css-in-js like styles-components or emotion, reducing dependencies.

4. Agnostic Components, what you create with React only works within React, what you create with Atomico works on the web, so you can use your components within React, Vue, Svelte or Html.

5. Exclusive component for React, the CLI @ atomico / exports automatically generates a wrapper component of your webcomponent for React, improving backward compatibility with React.

The following examples show some differences between React and Atomico.

From the example we will highlight the following differences:

1. In Atomico you only use one import.

2. useProp is like useState, but with the difference that useProp references the state from the webcomponent property defined in counter.props.

From the example we will highlight the following differences:

1. The hook api is the same.

2. the component in Atomico returns the `<host/> tag.

In Atomico you will have the most useful React hooks such as:

1. useRef

2. useState

3. useReducer

It is common to see the use of libraries such as Emotion or styled-components to encapsulate styles in React, but these add an additional cost, be it for performance or bundle, in Atomico there is no such cost.

Atomico integrates very easily into React, either using @atomico/exports or @atomico/react.

@atomico/exports

CLI that decorates the package.json according to the code to be exported in order to share your code optimally. By using the --wrappers flag the CLI will detect the export of webcomponents and automatically create a wrapper for React, Preact and Vue.

You can learn more about @atomico/exports in the following guide:

@atomico/react

With this package you will be able to create wrappers for your Webcomponents in React, even managing to make SSR of your webcomponents in environments like Next.js with these wrappers.

You can learn more about @atomico/react in the following guide:

Atomico escapes React DOM immutability logic and moves closer to the native DOM API, this means that Atomico at the scope level is only responsible for receiving the props and rendering the DOM, but it does not observe the internal mutations of the DOM automatically, this is because the native level mutations can come from anywhere, for example other libraries. Now for ensure state synchronization it is convenient that every webcomponent that wants to be observed has the obligation to dispatch a change event

You can easily achieve this by using useEvent or , applying that you can:

capture change as event

const [ value, setValue ] = useState("init"); // you can also use useProp

<host>
    <my-component 
        value={value} 
        onchange={({target})=>setValue(target.value)}
    ></my-component>
</host>

Force a fixed value

const update = useUpdate();

<host>
    <my-component 
        value={value} 
        onchange={update}></my-component>
</host>

the update function forces an update on the component, in order to redefine value according to the scope

The use of slots improves the composition allowing to reflect the content exposed in the lightDOM of the component in the shadowDOM of this, example:

::slotted(<selector>)

The slotted selector allows the manipulation of the content exposed as a lightDOM slot from the shadowDOM, example:

Auto slot

With Atomico you can define a default slot for your components, this is useful if you want to maintain some compositional consistency without the need to declare the use of slot, example:

To define a default slot, you only have to declare slot in the props, example:

Consider this practical only if the composition is leveraged to the container, this does not prevent you from modifying the slot property from the component instance.

Atomico has the hook that appends the slotchange event to a reference, this will allow you to hide slots if they do not declare content, example:

Introduction

Slots are a powerful feature when working with webcomponents that use the shadowDOM. And thanks to the hook @atomico/hooks/use-slot you will be able to observe the state of the slot and know the childNodes of this to manage the logic of the template. For example:

import { useRef } from "atomico";
import { useSlot } from "@atomico/hooks/use-slot";

function component() {
  const refSlotIcon = useRef();
  const slotIcon = useSlot(refSlotIcon);
  return (
    <host shadowDom>
      <slot
        name="icon"
        ref={refSlotIcon}
        style={slotIcon.length ? null : "display: none"}
      />
      <slot />
    </host>
  );
}

Thus managing to easily condition parts of our template to define the slots.

Another trick that useSlot allows us is the interaction at the DOM level, example:

import { useRef, useEffect } from "atomico";
import { useSlot } from "@atomico/hooks/use-slot";

function component() {
  const refSlotSlides = useRef();
  const slotSlides = useSlot(refSlotSlides);

  slotSlides.forEach((slide) => {
    slide.style.width = "100%";
    slide.style.height = "300px";
  });

  return (
    <host shadowDom>
      <slot name="slides" />
    </host>
  );
}

We can even apply filters per instance for a better identification of the node, example:

useSlot(refSlotSlides).filter(
  (childNode) => childNode instanceof HTMLDivElement
);

⚠️ In case of high ui computation use prefer to use slot modifiers inside a useEffect.

Slot pattern as a template

Slots are not only limited to a static definition, you can use them to identify a node and use it to create new nodes according to the logic of the webcomponent, example:

Thanks to useSlot(refSlotTemplateUser) we get the first node of the Template slot to be used in the iteration of the results obtained by fetch, with this we have eliminated the leverage of the webcomponent in charge of rendering the user at the level of our webcomponent userFetch

⚠️ the cloneNode property is available from version atomico@1.37.0

Normally we create webcomponents that only work with lightDOM or shadowDOM, example:

function componentWithLightDom() {
  return (
    <host>
      <h1>I am in the lightDOM</h1>
    </host>
  );
}

function componentWithShadowDom() {
  return (
    <host shadowDom>
      <h1>I am inside the shadowDOM</h1>
    </host>
  );
}

With atomico you can go further thanks to the hook @atomico/hooks/use-render which allows you to execute renders independent of the main one, example:

import { useRender } from "@atomico/hooks/use-render";

function componentWithLightDomAndShadowDom() {
  useRender(() => <h1>I am in the lightDOM</h1>);
  return (
    <host shadowDom>
      <h1>I am inside the shadowDOM</h1>
    </host>
  );
}

What are the benefits of using useRender?

1. Encapsulate DOM fragments within custom Hooks and then render to any webcomponent.

2. patch the limitations of webcomponents that use shadowDOM, to improve communication with forms.

With the useRender(...) fragment we are managing to render an input in the lightDOM, thanks to this we will be able to control said input from inside the webcomponent.

Thanks to useRender you will be able to work together with LightDOM and shadowDOM from the scope of the webcomponent created with Atomico.

The following format is friendly when sharing a webcomponent to NPM using @atomico/exports

├── src
│   ├── define.{js,ts,jsx,tsx}
│   ├── elements.{js,ts,jsx,tsx}
│   ├── define.test.{js,ts,jsx,tsx}
│   └── slots
│       ├── my-sub-element-1.{js,jsx,ts,tsx}
│       └── my-sub-element-2.{js,jsx,ts,tsx}
├── README.md
├── index.html
├── .npmignore
├── package.json
└── tsconfig.json
    

From the previous structure we highlight:

1. src/define: import the components from src/elements and declare them as customElements

2. src/elements: groups and export components as CustomElements

since it improves the customElements definition experience, example:

Thanks to @atomico/exports this is really easy, example:

You can see a use case of this structure in @atomico/components

Distribution and consumption

When creating design systems or component systems, we recommend that you maintain a centralized distribution structure in a single export package with multiple import paths, example:

import { Button, Input } 

import { Button } from "

What are the benefits of this type of distribution?

Aesthetic coherence, the entire design system leverages itself and thanks to this we gain aesthetic coherence.

While a monorepo might seem like an ideal path, it actually increases the complexity of maintenance, whether it be component versioning and dependency maintenance.

We move faster and reduce implementation errors if you don't rely on individual versioning at the component level and leave this only defined at the design system level.

This has its pros and cons:

Pros:

1. It speeds up the creation of components, since it avoids the individual publication process and centralizes all this at the design system level.

Cons

1. you will not be able to update a component individually, since it is leveraged at the design system level.

you always prefer to keep each component isolated in a directory with names associative to the same component, example:

why? The NPM-oriented packaging tool allows automatic export from the recommended structure,@atomico/exports will generate a modern package.json to current standards, automatically generating all (main, types, exports and more) what is necessary for your package to be distributed correctly.

Module

import { useClickCoordinates } from "@atomico/hooks/use-click-coordinates";

Syntax

useClickCoordinates(ref, handlerClick);

where:

1. ref: node reference to observe the click event.

2. handlerClick: Callback that receives the coordinates of the click event.

Coordinates

interface Coordinates {
  x: number;
  y: number;
  offset: {
    x: number;
    y: number;
  };
}

Where :

• x: MouseEvent.clientX

• y: MouseEvent.clientY

• offset.x : MouseEvent.offsetX

where:

1. src: javascript type resource to inject into document.head

2. done: optional , callback when called at the end of the script load

the useReflectEvent hook reflects the event from the reference origin to the reference destination, the captured event will be canceled

One of the possibilities of this hook is to reflect the events inside shadowDOM to lightDOM, example when using forms

module

import { 
    useReflectEvent, 
    reflectEvent  
} from "@atomico/hooks/use-reflect-event";

Syntax useReflectEvent

useRefectEvent will listen for the eventType of refFrom, to reflect it on refTo

Syntax reflectEvent

Reflects on an element the given event

Module

import { useKeyboard } from "@atomico/hooks/use-keyboard";

Syntax

useKeyboard(
    ref: Ref<Element>,
    keysCode: string[],
    callback: (event: KeyboardEvent)=>void
);

where:

1. ref, the reference to associate the event keydown and keyup.

2. keysCode: key combination to capture

3. callback: receives the last event of the key combination

Module

import { 
    useForm, 
    useFormListener, 
    useFormInputHidden, 
    useFormInputRadio 
} from "@atomico/hooks/use-form";

useForm syntax

If the webcomponent is nested within a form tag, this hook will return that form tag as a reference.

const ref = useForm()

useFormListener syntax

If the webcomponent is nested within a form tag, you will be able to listen to events from that tag through useFormListener.

useFormListener("reset",handler);

useFormInputHidden syntax

el hook renderiza un input hidden en el lightDOM cuyo name y value del input seran los parametros que el hook resiva

useFormInputHidden("my-field","my-value");

useFormInputRadio

One of the difficult inputs to standardize when working with shadowDOM is the radio input, thanks to this hook you will be able to create and observe a radio input synchronized with the form and its webcomponent.

This hook requires the definition of the properties in its webcomponent:

myComponent.props = { name: String, checked: Boolean }

You can work with the input from the component logic, example:

Your component will automatically be reactive to the change of the states of the radio input

Module

import { useDebounceState } from "@atomico/hooks/use-debounce-state";

Syntax

this hook is similar to useState, but the purpose of this hook is to bottleneck the state at update time

const [state, setState] = useDebounceState(
    delay:number, 
    initialState: any,
    mode?: "fps" | "timeout" | "idle"
);

mode differences

1. fps:

   1. if delay is set to 1, the update is executed for each cycle of requestAnimationFrame(60fps),

   2. if delay is defined as 2, the update is executed for every 2 cycle of requestAnimationFrame(30fps)

2. timeout: the delay will be the milliseconds for setTimeout

3. idle : the delay will be the milliseconds for requestIdleCallback

Inherit the disabled status of a parent tag type fieldset, under certain rules:

1. The label must be on the lightDOM.

2. The component that uses this hook must declare the prop {disabled: Boolean}.

Where:

1. matches: Optional string, allows to change the search of the parent tag fieldset for another tag or selector compatible with .

Inject tag style into shadowRoot with content given as parameter to use CSS.

Import

import { useCss } from "@atomico/hooks/use-css";

Sintaxis

useCss(cssText: string);

Example

Note

This hook was not created as a replacement for component.styles, it is rather a utility that seeks to facilitate the integration of css from a customHook, either by defining a state or another action.

Module

import { useCopy } from "@atomico/hooks/use-copy";

Syntax

const copy:()=>void = useCopy(ref);

Where:

1. ref : Node reference to copy

2. copy: Callback, executes the content copy event.

Example

Module

import { useParent, useParentPath } from "@atomico/hooks/use-parent";

Syntax useParent

const selector = "form";
const parent = useParent(selector);

Where:

• selector: String, Selector to be used by Element.matches when searching for the parent.

• parent: Element, ascending search result according to selector.

Where:

• parents: parent nodes of the webcomponent

• composed: bypasses shadow DOM in parent capture.

Module

import {
  useResizeObserver,
  useResizeObserverState,
} from "@atomico/hooks/use-resize-observer";

Syntax

useResizeObserver

useResizeObserver(
  ref,
  (rect) => void
);

Where:

• ref: Ref, reference to observe the resizing.

• rect: Object, the return of DOMRectReadOnly.toJSON(), documentation of

  • width

  • height

  • x

Where:

• ref: Ref, reference to observe the resizing.

• rect: Object, the return of DOMRectReadOnly.toJSON(), documentation of

Module

import { usePromise } from "@atomico/hooks/use-promise";

Syntax

const [result, status] = usePromise(
  asyncFunction,
  runFunction,
  optionalArguments
);

Where :

• result: Retorno de la promesa

• status: Estado de la promesa:

  • "": Without executing.

  • "pending": In action.

  • "fulfilled": Successfully executed.

  • "rejected": Executed with error.

• asyncFunction: asynchronous function.

• runFunction: Booleano, if true it will execute the promise and define the status.

• optionalArguments: Optional any[], allows to regenerate the promise through arguments.

import { c } from "

import { c } from "

Atomico simplifies learning, workflow and maintenance when creating webcomponents and achieves it with:

1. Scalable and reusable interfaces: with Atomico the code is simpler and you can apply practices that facilitate the reuse of your code.

2. Open communication: with Atomico you can communicate states by events, properties or methods.

3. Agnostic: your custom Element will work in any web-compatible library, eg React, Vue, Svelte or Angular.

4. Performance: Atomico has a comparative performance at Svelte levels, winning the third position in performance according to in a comparison of 55 libraries among which is React, Vue, Stencil and Lit.

First let's say that Atomico is light since it has a size close to 3kB vs React + ReactDOM that have a size close to 60kB, now if your project is already written in React I can integrate Atomico progressively since a component created can be instantiated as a component for React thanks to @atomico/react, example:

import { Button } from "@formas/button/react";

function App(){
   return <>
      <h1>React App!</h1>
      <Button onClick={()=>console.log("Click!")}>
         Submit
      </Button>
   </>
}

Magical 🪄, isn't it?... well now let's speed up your Atomico learning path:

How to declare a component?

Atomico, like React, allows a declaration of components using only functions, example:

import { useState } from "

import { c, useProp } 

From the example we will highlight the following differences:

1. In Atomico you only use one import.

2. useProp is like useState, but with the difference that useProp references the state from the webcomponent property defined in counter.props.

3. const props

Now I want to invite you to learn how to declare a style using Atomico.

It is common to see the use of libraries such as Emotion or styled-components to encapsulate styles in React, but these add an additional cost, be it for performance or bundle, in Atomico there is no such cost.

It is normal for React to create components that you then instantiate within other components, for example:

with Atomico there are certain differences:

The constructor in Atomic is the product of the c function and is the one you will use to register your webcomponent, example:

According to the previous example, you can instantiate MyComponent as a JSX Component, example:

This instance type allows autocompletion at the JSX level and type validation at the Typescript level.

This will be useful for reusing templates, but always remember stateless.

Now, Atomico includes a context API as part of its core. We recommend implementing it as an alternative to using useChannel.

An alternative to React's context but solely based on hooks.

Modulo

import { useChannel } from "@atomico/hooks/use-channel";

Syntax

const channel = "MyChannel";
const [parentValue, setChildValue] = useChannel(channel);

Where :

1. channel: String, defines the name of the event to be used to generate the channel.

2. parentValue: Value inherited by the parent component.

3. setChildValue: Callback, defines a value for nested components.

This hook is used by

We invite you to discover part of the development experience you will get with Atomico:

Quick components to write since with Atomico you will require fewer lines of code to declare your webcomponents which will help you to be more productive

Fast in performance, since Atomico sends less code to the client, making your interface load quickly

This is thanks to a functional orientation inherited from React hooks plus some internal optimization from Atomic that ease the process of shaking the tree at compile time, achieving in this way sending the client a highly optimized JS that only has what you really use

This is thanks to Atomico's reliance on React hooks syntax plus the ability to completely eliminate the need for this when using webcomponents.

Where:

1. ref: Reference of the slot to observe.

2. childNodes: List of nodes assigned to the observed slot.