eagerpatch / navita Goto Github PK

Next.js has changed their default config file name to next.config.mjs.

When running with import createNavitaStylePlugin from '@navita/next-plugin', we get a runtime error saying that the MiniCssExtractPlugin can't be found. Probably just needs the file extension.

It would require creating a runtime adapter that uses the engine and inserts styles into the DOM.

This should be possible:

const animation = keyframes({
  '0%': { content: '' },
  '25%': { content: '.' },
  '50%': { content: '..' },
  '75%': { content: '...' },
  '100%': { content: '' },
});

Without having to explicitly quote the values.

Our loader runs too early in some cases. If we include our loader too late in the process, some of our identifiers might've been three shaken away (such as globalStyle).

If we include it too early, and user code in Navita rely on other transforms that also happens, our evaluation process will fail.

So, maybe two loaders? One that finds modules that might be tree shaken away, and does something to/with them, and then the one we have now, but to make sure it runs last.

I've come across at least one case where we need to control the CSS specificity better. It's mainly if the user is specifying the declaration:

all: unset;

Rules in a specific list needs to be rendered before rest of the CSS, and possibly live in a separate layer. Right now I can only think of "all: unset" specifically, but it should be pretty easy to just sort the rules in the css printer.

Can this be a solid replacement to styled components?

How would this work with dynamic styling based on props similar to styled-components? Also can you update the docs with a section that talks about migrating from styled-components?

const x = style({
  '&:hover': {
    background: 'red',
  }
});

const x2 = style({
  '&:active': {
    background: 'red',
  }
});

Will produce the following css:

.a1:hover {
  background: red;
}

.b1:active {
  background: red;
}

But it could produce the following CSS to save a few bytes:

.a1:hover, .b1:active {
   background: red;
}

Using Navita imports directly inside routes that has

export const runtime = 'edge';

Causes the compiler to hang.

I can't remember the details of the Next.js implementation completely, but it might be caused by this line:
https://github.com/vercel/next.js/blob/f3132354285fb18c290bf9aad7f8dc7e0550105d/packages/next/src/build/webpack/plugins/flight-client-entry-plugin.ts#L614

Needs investigation and replication.

Lines in Navita that we need to look into:

const borderBottomColor = createVar('borderBottomColor');

const x = style({
  [borderBottomColor]: 'red',
});

The generated css from "x" is --border-bottom-color: red. The variables should probably be left as they are, and createVar etc should generate snake-case vars instead - maybe.

If you remove a navita call, without removing the import to the navita call, MagicString will sometimes get the wrong result.

This looks like an interesting project so I thought I'd give it a go for a use case of mine.

I'm building a component library which would then use @navita/css to then generate the css for the component.

In the application, component is imported and styles would be overridden using @navita/css. Moreover, it would be a case of last object wins.

2 questions:

1. I've tried to use @navita/css within the component lib, however I get the error

Error: Could not find an adapter. Please ensure you have added a bundler integration:

Is it possible to run @navita/css without an adapter present? In this case, only react is present.

2. How does the creation of styles work? Is it like pandacss where it runs through the whole of the html payload and generates the styles? Would style creation work over the file boundary?

Here is an example from pandacss: https://panda-playground.vercel.app/tZQo-P_psO

Thanks

const color = createVar('color');

const x = style({
   background: `rgba(${color}, 0.15)`,
});

Will produce this css:

.a1 {
   background: rgba(--color, 0.15);
}

Instead of this:

.a1 {
   background: rgba(var(--color), 0.15);
}

Source:
https://github.com/eagerpatch/navita/blob/main/packages/engine/src/helpers/normalizeCSSVarsValue.ts#L3

At first glance, it looks like the regex is still valid, but we need to expand the test cases, and modify or remove the if-statement that decides if we should normalize CSS var values.

As I almost mentioned in #43, the caching mechanism we're using right now, always assumes in-memory usage.

This works very well as it is right now, but the way the code is structured could be better. If we reach for a more flat structure, it would be easier to expand/replace to another type of persistent storage later. Right now we're also pretty inefficient in the way we are storing data for the cache

Here's an example entry:

"{\"type\":\"rule\",\"selector\":\"\",\"property\":\"padding\",\"value\":\"20px\",\"pseudo\":\"\",\"media\":\"\",\"support\":\"\",\"container\":\"\"}": {
  "id": "b1",
  "type": "rule",
  "selector": "",
  "property": "padding",
  "value": "20px",
  "pseudo": "",
  "media": "",
  "support": "",
  "container": ""
},

The key is the value, just stringified, and without the id.