Forem: Radu Brehar👨‍💻

How to use Excel-like editing in your DataGrid

Radu Brehar👨‍💻 — Thu, 13 Jun 2024 08:39:08 +0000

Excel-like editing is a very popular request we had. In this short article, we show you how to configure Excel-like editing in the Infinite React DataGrid.

Click on a cell and start typing

This behavior is achieved by using the Instant Edit keyboard shorcut.

Configuring keyboard shortcuts

import {
  DataSource,
  InfiniteTable,
  keyboardShortcuts
} from '@infinite-table/infinite-react';

 function App() {
  return <DataSource<Developer> primaryKey="id" data={dataSource}>
    <InfiniteTable<Developer>
      columns={columns}
      keyboardShortcuts={[
        keyboardShortcuts.instantEdit
      ]}
    />
  </DataSource>
}

The instantEdit keyboard shorcut is configured (by default) to respond to any key (via the special * identifier which matches anything) and will start editing the cell as soon as a key is pressed. This behavior is the same as in Excel, Google Sheets, Numbers or other spreadsheet software.

To enable editing globally, you can use the columnDefaultEditable boolean prop on the InfiniteTable DataGrid component. This will make all columns editable.

Or you can be more specific and choose to make individual columns editable via the column.defaultEditable prop. This overrides the global columnDefaultEditable.

Column Editors

Read about how you can configure various editors for your columns.

Editing Flow Chart

A picture is worth a thousand words - see a chart for the editing flow.

Finishing an Edit

An edit is generally finished by user interaction - either the user confirms the edit by pressing the Enter key or cancels it by pressing the Escape key.

As soon as the edit is confirmed by the user, InfiniteTable needs to decide whether the edit should be accepted or not.

In order to decide (either synchronously or asynchronously) whether an edit should be accepted or not, you can use the global shouldAcceptEdit prop or the column-level column.shouldAcceptEdit alternative.

When neither the global shouldAcceptEdit nor the column-level column.shouldAcceptEdit are defined, all edits are accepted by default.

Once an edit is accepted, the onEditAccepted callback prop is called, if defined.

When an edit is rejected, the onEditRejected callback prop is called instead.

The accept/reject status of an edit is decided by using the shouldAcceptEdit props described above. However an edit can also be cancelled by the user pressing the Escape key in the cell editor - to be notified of this, use the onEditCancelled callback prop.

Using shouldAcceptEdit to decide whether a value is acceptable or not

In this example, the salary column is configured with a shouldAcceptEdit function property that rejects non-numeric values.

Persisting an Edit

By default, accepted edits are persisted to the DataSource via the DataSourceAPI.updateData method.

To change how you persist values (which might include persisting to remote locations), use the persistEdit function prop on the InfiniteTable component.

The persistEdit function prop can return a Promise for async persistence. To signal that the persisting failed, reject the promise or resolve it with an Error object.

After persisting the edit, if all went well, the onEditPersistSuccess callback prop is called. If the persisting failed (was rejected), the onEditPersistError callback prop is called instead.

Master-Detail React DataGrid with Charts

Radu Brehar👨‍💻 — Mon, 10 Jun 2024 15:12:28 +0000

In this article, I want to show you how easy it is to leverage the master-detail support in the Infinite Table React DataGrid in order to toggle between a table and a chart view in the row detail.

In the RowDetail component of Infinite Table, we render a <DataSource />, which in turn will render either an <InfiniteTable /> component or a chart.

The <DataSource /> in InfiniteTable is very powerful and does all the data processing the grid needs. All the row grouping, sorting, filtering, aggregations, pivoting are done in the <DataSource /> - so you can use it standalone, or with InfiniteTable - it's totally up to you.

In practice, this means that you can use the <DataSource /> to process your data and then simply pass that to a charting library like ag-charts-react.

const detailGroupBy: DataSourcePropGroupBy<Developer> = [{ field: "stack" }];
const detailAggregationReducers: DataSourcePropAggregationReducers<Developer> =
  {
    salary: {
      field: "salary",
      initialValue: 0,
      reducer: (acc, value) => acc + value,
      done: (value, arr) => Math.round(arr.length ? value / arr.length : 0),
    },
  };

function RowDetail() {
  const rowInfo = useMasterRowInfo<City>()!;
  const [showChart, setShowChart] = React.useState(rowInfo.id % 2 == 1);

  return (
    <div style={{...}}>
      <button onClick={() => setShowChart((showChart) => !showChart)}>
        Click to see {showChart ? "grid" : "chart"}
      </button>

      {/**
       * In this example, we leverage the DataSource aggregation and grouping feature to
       * calculate the average salary by stack for the selected city.
       */}
      <DataSource<Developer>
        data={detailDataSource}
        primaryKey="id"
        groupBy={detailGroupBy}
        aggregationReducers={detailAggregationReducers}
      >
        {/**
         * Notice here we're not rendering an InfiniteTable component
         * but rather we use a render function to access the aggregated data.
         */}
        {(params) => {
          // here we decide if we need to show the chart or the grid
          if (!showChart) {
            return (
              <InfiniteTable
                columns={detailColumns}
                domProps={{
                  style: { paddingTop: 30 },
                }}
              />
            );
          }

          // the dataArray has all the aggregations and groupings done for us, 
          // so we need to retrieve the correct rows and pass it to the charting library
          const groups = params.dataArray.filter((rowInfo) => rowInfo.isGroupRow);
          const groupData = groups.map((group) => ({ stack: group.data?.stack, avgSalary: group.reducerData?.salary }));

          return (
            <AgChartsReact
              options={{
                autoSize: true,
                title: {
                  text: `Avg salary by stack in ${rowInfo.data?.name}, ${rowInfo.data?.country}`,
                },
                data: groupData,
                series: [
                  {
                    type: "bar",
                    xKey: "stack",
                    yKey: "avgSalary",
                    yName: "Average Salary",
                  },
                ],
              }}
            />
          );
        }}
      </DataSource>
    </div>
  );
}

The demo above is using the ag-charts-react package to render the charts.

The best testing strategies for frontends

Radu Brehar👨‍💻 — Mon, 22 Apr 2024 13:28:59 +0000

In our previous article, we focused on documenting the best testing setup for frontends, which used Playwright and Next.js. You can check out the repository here where you can find the full setup.

We consider the combination described above, Playwright + NextJS being the best combo around for testing frontends. Ok, you can switch out NextJS with other meta-framework that offers file-system routing, but the idea is the same: every test is made of 2 sibling files, with the same name but different extension.

In the test files, Playwright is configured to navigate automatically to the page being tested, so no need for adjustments if you move files around. This saves you a lot of time and hustle and makes your tests more robust and focused.

But in addition to end-to-end testing with Playwright and NextJS, there are other forms of testing out there which are available and can be used to complement your testing strategy. In this article, we'll focus on what we think are the best testing strategies for frontends. So here are a few options:

E2E testing
Component testing
Visual regression testing
Unit testing

For each of those options there are plenty of tools you can use, each with its own pros and cons.

E2E testing

With the advent of tools like Puppeteer and now Playwright, end-to-end testing has become much easier and more reliable. For anyone who's used Selenium in the past, you know what I'm talking about.
Puppeteer has opened the way in terms of E2E tooling, but Playwright has taken it to the next level and made it easier to await for certain selectors or conditions to be fulfilled (via locators), thus making tests more reliable and less flaky.
Also, it's a game changer that it introduced a test-runner - this made the integration between the headless browser and the actual test code much smoother.

Reasons to use E2E

End to end testing is actually a real browser, so the closest possible environment to what your app will be using.

No need to fake the page with JSDOM, no need to only do shallow rendering in React. Just use the platform!

Component testing

Probably Enzyme was the first to popularize component testing in React by doing shallow rendering and expecting some things to be there in the React component tree. Then React Testing library came and took component testing to a whole new level.

The tools are great for what they're doing, but with the advent of better tooling, we should move on to better ways of testing. With the tools we have now in 2024, there's no more need to use JSDOM and simulate a browser enviroment. It used to be very cumbersome to start a headless browser back in the day, but now with Playwright/Puppeteer, it's a breeze.

Visual regression testing

Also in the days before Playwright was around, there was much hype about visual regression testing. It was very very tempting to use it - who wouldn't want to have a tool that automatically checks if the UI has (mistakenly) changed? It might fit a few use-cases, but in general, it's not worth the effort of maintaining all those tests for any little change in the UI. True, you can set thresholds for the differences, but it's still a lot of work to maintain it, especially in highly dynamic frontends and teams.

With better CSS approaches like TailwindCSS and Vanilla Extract (which we're heavily using) it's much easier to maintain the UI and make sure it doesn't change unexpectedly. No more conflicting CSS classes, much less CSS specificity issues and much less CSS code in general.

One of the troubles in large and tangled CSS codebases is that it's write-only. Well, not write-only per se, but teams are generally afraid to remove a line of CSS cause it might break someone else's code or it might still be used.

With Vanilla Extract you can be sure that if you remove a CSS class, it's not used anywhere else in the codebase. It's been a game changer in terms of CSS maintainability and productivity for us at Infinite Table.

So with all those tools to make styling easier, the need for visual regression testing has dropped significantly.

Unit testing

Unit testing will be here to stay - at least if besides your UI, your app has some significant business logic. We're using it in combination with E2E testing to make sure complex use-cases work as expected.

For example, our logic for row grouping is fully tested with unit tests. We do have E2E tests for it, but with unit tests we can have full coverage of all the nitty-gritty details of the grouping logic. We do the same for pivoting and aggregating. Column sizing and column grouping are also covered with unit tests.

We think there's always going to be a place for unit testing to ensure robustness and reliability of the app under even the most complex use-cases and user inputs.

Conclusion

In our experience, the best testing strategy for modern frontends is a combination of E2E testing (using Playwright+NextJS), and unit testing. Visual regression testing is not worth the effort in our opinion, especially with the advent of better CSS tooling like TailwindCSS and Vanilla Extract.

Though we used shallow component testing in the past, we're not going back to it - mocking the DOM and the browser is no longer worth it when you can use a real browser with Playwright.

We hope this article has been helpful in guiding you towards the best testing strategy for your frontend. If you have any questions or comments, feel free to reach out to us at admin@infinite-table.com. We're always happy to help!

The best testing setup for frontends, with Playwright and NextJS

Radu Brehar👨‍💻 — Thu, 18 Apr 2024 09:36:38 +0000

We want to share with you the best testing setup we've experienced - and this includes using Playwright and NextJS. It's a setup we've come up with for Infinite React DataGrid, which is a complex component, with lots of things to test, but this configuration has helped us ship with more confidence and speed.

What you should expect from a testing setup

Fast feedback

⚡️ Quick ⚡️ feedback is a no-brainer, since without a fast turnaround, devs will not have the patience to run the tests and will move on to the next "burning" issue or to the next cup of coffee.

Also, you can't run all the test suite at once, so you need to be able to run only the tests that are relevant to the changes you've made. This has long been available in unit-testing frameworks, but it's not so common in end-to-end testing, when loading a webpage and rendering an actual component is involved.

In this article we want to show you how we achieved fast feedback that allows rapid developer iterations.

Stability and predictability

You don't need flaky tests that fail randomly - it's the last thing you want when doing a release, or even during development.
Waiting for an element to appear on page or an animation to finish or an interaction to complete is a common source of flakiness in end-to-end tests, but Playwright gives you the tools to address these issues - thank you Playwright locators 🙏 and other playwright testing framework features.

Ease of maintenance and debugging

Another crucial point when you setup a testing framework and start writing tests is how easy is to write a new test, to inspect what is being tested and to reproduce failing tests. All these should be as easy as opening loading a URL in a browser - this is exactly what this setup gives you, with NextJS and Playwright playing very well together.
When one of your tests fails, Playwright outputs a command you can run to reproduce the exact failure and actually see the UI at the moment of the failure, with the ability to navigate through the test timeline and see what happened before the failure.

Setting up NextJS and Playwright

Step 1 - creating the NextJS app

$ npx create-next-app@latest

You're being asked a few questions. For Would you like to use src/ directory? we chose Yes. Also, we're using TypeScript.

When you run this command, make sure for this question Would you like to use App Router? you reply No, as you want to use file-system routing to make it very easy and intuitive to add new pages and tests.

Check out our repo for this stage of the setup - Step 1 - setting up NextJS.

Before you go to the next step, you can configure your next.config.mjs to use the .page extension for your pages.

const nextConfig = {
  reactStrictMode: true,
  pageExtensions: ["page.tsx", "page.ts", "page.js"],
};
export default nextConfig

This is useful so NextJS will only compile those files as pages that your tests will be targeting, and not all the files in the pages folder, which will also contain your tests.

So you know all your .page files are pages that your tests will be run against and all your .spec files are tests (see next step).

Step 2 - setting up Playwright

$ npm init playwright@latest

Again a few questions about your setup.

Where to put your end-to-end tests? - choose src/pages - which makes your NextJS pages folder the place where you put your end-to-end tests.

This script installs @playwright/test and creates a playwright.config.ts file with the default configuration. Most importantly, the testDir is configured to ./src/pages.

By default, all .spec files in the testDir (which is set to src/pages) will be run as tests.

Check out our repo for this stage of the setup - Step 2 - setting up Playwright.

There are some additional configurations you might want to do in this step.
You probably want to change the default reporter from 'html' to 'list' in your playwright.config.ts - the 'html' reporter will open a browser window with the test results, which you might not prefer. You'd rather see the results in the terminal.

// playwright.config.ts
export default defineConfig({
  testDir: "./src/pages",
  reporter: "list", // the 'html' reporter will open a browser window with the test results
  // ...
})

For now, you might want to only run your tests in one browser, so comment out any additional entries in the projects array in your playwright.config.ts file - that controls the devices that will be used in your tests.

The last piece of the puzzle before running your first test with Playwright is defining the test script in your package.json.

{
  "name": "testing-setup-nextjs-playwright",
  "scripts": {
    "test": "npx playwright test",
    "dev": "next dev",
    "build": "next build",
  },
}

Executing the npm run test command will run the tests in the src/pages folder - for now, you should have a single file, example.spec.ts, which was generated by the npm init playwright command.

Your initial test file was something very basic. This file is importing the test (and expect) function from @playwright/test - and this is what you're using to define tests (and write assertions).

// example.spec.ts
import { test, expect } from "@playwright/test";

test("has title", async ({ page }) => {
  await page.goto("https://playwright.dev/");

  // Expect a title "to contain" a substring.
  await expect(page).toHaveTitle(/Playwright/);
});

Step 3 - configuring the naming convention in Playwright to open the right pages

This step is probably the most important one in your configuration. Normally your tests will open webpages before you start testing - but this is not something you want to do explicitly in your project. Rather, you want your tests to automatically navigate to the corresponding page for the test. This is what this step is achieving - and we're using Playwright fixtures to do this.

Think of a fixture as some code that's configuring the testing environment for each of your tests.
A fixture will extend the test function from @playwright/test with additional functionalities. Mainly, we want before every test to open the correct page, without writing this explicitly in every test. Based on the location of the test file in the file system, we want to navigate to a webpage for it and we assume it will have the same path as the test file. This is possible because NextJS is configured to use file-system routing.

// Defining the fixture file - test-fixtures.ts

import {
  test as base,
  expect,
  PlaywrightTestArgs,
  PlaywrightTestOptions,
  Page,
} from "@playwright/test";

export * from "@playwright/test";

export const test = base.extend<
  PlaywrightTestArgs &
    PlaywrightTestOptions
>({
  //@ts-ignore
  page: async ({ baseURL, page }, use, testInfo) => {
    const testFilePath = testInfo.titlePath[0];
    const fileName = testFilePath.replace(".spec.ts", "");
    const url = `${baseURL}${fileName}`;

    // navigate to the corresponding page for this test
    await page.goto(url);

    await use(page);
  },
});

We'll give this fixture file the name test-fixtures.ts and put it in the root of the project.

Now instead of importing the test function from @playwright/test we want to import it from the test-fixtures.ts file - we'll do this in all our tests. To make this easier, let's also define a path alias in the tsconfig.json file.

{
  "compilerOptions": {
    "paths": {
      "@playwright/test": ["test-fixtures.ts"],
    }
  }
}

We're ready to write our first test page in NextJS and use the new fixture in the Playwright test.

// src/pages/example.page.tsx
export default function App() {
  return <div>Hello world</div>;
}

// src/pages/example.spec.ts
import { test, expect } from "@testing"; // notice the import

test("Main example has corrent content", async ({ page }) => {
  // notice we don't need to navigate to the page, this is done by the fixture
  await expect(await page.innerText("body")).toContain("Hello world");
});

For our tests against the NextJS app, we obviously need to start the app.

Let's configure a custom port of 5432 in the package.json dev script.

{
  "scripts": {
    "dev": "next dev --port 5432",
    "test": "npx playwright test"
  }
  //...
}

We need to use the same port in the Playwright configuration file.
Also we'll use a smaller test timeout (the default is 30s).

// playwright.config.ts
import { defineConfig } from "@playwright/test";
/**
 * See https://playwright.dev/docs/test-configuration.
 */
export default defineConfig({
  testDir: "./src/pages",
  reporter: "list",
  use: {
    baseURL: "http://localhost:5432/",
  },
  timeout: process.env.CI ? 10000 : 4000,
  // ... more options
});

We're now ready to roll!

npm run dev will run NextJS and npm run test will run the tests against your NextJS app.

To make the setup easier, avoid using index.page.tsx pages in NextJS - give your pages another name, to avoid issues with directory index pages in tests. This can easily be solved in the test fixture, but for the sake of clarity and brevity we're not doing it now.

Check out our repo for this stage of the setup - Step 3 - configuring the Playwright fixture and naming convention.

Step 4 - adding watch mode

As we mentioned initially, no testing setup is great unless it gives you very fast feedback. For this, we obviously need watch mode.

We want to be able to re-run tests when our test code has changed, but even better, when our NextJS page has changed - so the page the test is running against.
NextJS has watch mode built-in in dev mode, so whenever a page is changed, it's recompiled and the browser is served the updated page. We'll use this in our advantage, so tests will always see the latest version of the page.
This means the last piece of the puzzle is to make Playwright re-run the tests when the page has changed or the test itself has changed.

For this, we'll use chokidar - more specifically the chokidar-cli package. chokidar is probably the most useful file watching library for the nodejs ecosystem and it will serve us well.

{
  "scripts": {
    "test": "npx playwright test",
    "test:watch": "chokidar '**/*.spec.ts' '**/*.page.tsx' -c 'test_file_path=$(echo {path} | sed s/page.tsx/spec.ts/) && npm run test -- --retries=0 ${test_file_path}'"
  }
}

The test:watch script is watching for changes in .spec.ts files and .page.tsx files and whenever there's a change in one of those files, it's re-running the respective test. (When a change was found in a .page.tsx file, we're using sed to replace the .page.tsx extension with .spec.ts, because we want to pass the test file to the npm run test command so it knows what test to re-run.)

The above test:watch script was written for MacOS (and Unix-like systems). If you're using Windows, you might need to adjust the command to achieve the same result.

Don't forget to run npm run dev before running npm run test or npm run test:watch - you need the NextJS app running to be able to run the tests. After all, that's what you're testing 😅.

Step 5 - running tests on production build

In the last step, we want to build a production build of the NextJS app and run the tests against it.

So first let's configure the next.config.mjs file to build a static site when npm run build is run.

// next.config.mjs - configured to export a static site
const nextConfig = {
  reactStrictMode: true,
  output: "export",
  pageExtensions: ["page.tsx", "page.ts", "page.js"],
};

export default nextConfig;

Notice the "output": "export" property. Having configured this, the npm run build will create an /out folder with the compiled assets and pages of the app.

Next we need an NPM script to serve the compiled app with a static server.

{
  "scripts": {
    "serve": "npx http-server --port 5432 out",
    "//...": "// other scripts"
  },
}

We could either run this serve script ourselves to start the webserver before running our tests or even better, we can instruct Playwright to use this webserver automatically. So let's do that in our playwright.config.ts file.

// playwright.config.ts - configured to use a custom server
export default defineConfig({
  //... other options

  // on CI, run the static server to serve the built app
  webServer: process.env.CI
    ? {
        command: "npm run serve",
        url: "http://localhost:5432",
        reuseExistingServer: true,
        timeout: 120 * 1000,
      }
    : undefined,
})

In order for Playwright to correctly detect the webserver is running ok, we need to make sure we have a valid index page at that address, so we need to add a index.page.tsx file in the pages folder.

// src/pages/index.page.tsx
export default function App() {
  return <div>Index page</div>;
}

This is just useful in the CI environment so that Playwright can detect the server is running and the app is served correctly.

Next, in order to run our tests as if we're in the CI environment, let's add a test:ci script, which is basically calling the test script but setting the CI environment variable to true.

{
  "scripts": {
    "test:ci": "CI=true npm run test",
    "test": "npx playwright test",
    "serve": "npx http-server --port 5432 out",
    "//...": "// other scripts"
  },
}

We're now ready to run our tests against the production build of the NextJS app.

npm run build && npm run test:ci

This script first builds the NextJS static app and then runs the tests against it.

Configuring CI github actions

We're now ready to integrate our testing workflow into CI via Github actions.

Create a YAML file .github/workflows/test.yml in the root of your project with the following content.

name: Playwright Tests
on:
  push:
    branches: [main, master]
  pull_request:
    branches: [main, master]
jobs:
  test:
    timeout-minutes: 60
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: lts/*
      - name: Install dependencies
        run: npm ci
      - name: Build app
        run: npm run build
      - name: Install Playwright Browsers
        run: npx playwright install --with-deps
      - name: Run Playwright tests
        run: npm run test
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

With this, you're ready to go! Push your changes to the main branch and see your tests running and passing in the CI environment. Go green! 🟢

Demo repository

You can find the full setup in our testing-setup-nextjs-playwright repo. Check it out and give it a star if you find it useful.

Profit 🚀

With this setup, you have a very convenient way to write your tests against real pages, loaded in a real browser, just like the end user experiences. And with the watch mode giving you instant feedback, you no longer have an excuse to not write tests.

This is the same setup we've been using for developing and testing the Infinite Table React DataGrid and it has been serving us really well.

DataGrids are some of the most complex UI components one can build, so having a reliable tool that allowed us to iterate very quickly was crucial to us. This helped us add new features, while being confident that all of the existing core functionalities like row/column grouping, filtering, sorting, pagination, pivoting still work as expected.

The setup was a pivotal point in our development process and it's what gives us and our enterprise customers the peace of mind that the product is stable and reliable, both now and in the future.

Master detail is now available in Infinite React DataGrid

Radu Brehar👨‍💻 — Tue, 05 Mar 2024 11:50:35 +0000

Today is a big day for the Infinite React DataGrid - we're excited to announce that the master detail feature is now available!

With this addition, our DataGrid is now enterprise-ready! We know master-detail scenarios are needed in many business applications, and we're happy to provide this feature to our users starting today!

Master-detail highlights 🎉

1️⃣ support for multiple levels of master-detail & rendering custom content
2️⃣ configurable detail height
3️⃣ control over expand/collapse state
4️⃣ caching mechanism for detail DataGrids

What can you do with master-detail?

Master-detail allows you to have rows in the DataGrid that expand to show more details. This can be used to show more information about the row, or even to show another DataGrid with related data.

You can render basically anything in the detail row - it doesn't need to be another DataGrid. However, if you do want to show another DataGrid, you can, and you can do that at any level of depth.

In the detail <DataSource /> component, you have access to the master row, so it will be very easy to load related data based on the master row the user expands.

Configurable detail height

Our master-detail implementation is very configurable - you can control the height of the row details, the expand/collapse state, and much more.

The height of the row details is fully adjustable - see the rowDetailHeight prop to learn about all the options you have.

As seen in the snippet above, it's also really easy to control the expand/collapse state of the row details. You can choose to have some rows expanded by default so details of those rows will be visible from the start.

Configurable expand/collapse state

Using the rowDetailState, you can control (in a declarative way) which rows are expanded and which are collapsed. In addition, if you prefer the imperative approach, we also have an API to work with row details.

If you have some rows with details and some without, that's also covered. Use the isRowDetailEnabled to control which rows will have details and which will not.

Another important configuration is choosing the column that has the row detail expand/collapse icon. Use the columns.renderRowDetailIcon prop on the column that needs to display the expand/collapse icon. If this prop is a function, it can be used to customize the icon rendered for expanding/collapsing the row detail.

Master detail caching

By far the most common scenario will be to render another DataGrid in the detail row.

For such cases we offer a caching mechanism that will keep the state of the detail DataGrid when the user collapses and then expands the row again.

To enable caching, use the rowDetailCache prop.

It can be one of the following:

false - caching is disabled - this is the default
true - enables caching for all detail DataGrids
number - the maximum number of detail DataGrids to keep in the cache. When the limit is reached, the oldest detail DataGrid will be removed from the cache.

This example will cache the last 5 detail DataGrids - meaning they won't reload when you expand them again.
You can try collapsing a row and then expanding it again to see the caching in action - it won't reload the data.
But when you open up a row that hasn't been opened before, it will load the data from the remote location.

Read our docs on caching detail DataGrids to learn more how you can use this feature to improve the user experience.

Write-only social media?

Radu Brehar👨‍💻 — Thu, 05 Oct 2023 13:02:57 +0000

How do you all manage your digital interactions?

As developers, we're tempted to spend countless hours reading the latest trends, following the latest tech, keeping up-to-date with the latest news, and so on. And all of this can be very draining.

I've been there myself and I can't say I'm now immune to this - I'm still learning how to keep my sanity, remain informed but be productive at the same time.

One of the most important things is to realise life is too short to keep up with everything. You can't know it all and you can't be everything. Be content with who you are! And be a professional at the same time. Know your tools and sharpen them, but don't try to learn every single tool out there - it's not gonna work. Sure, experimentation has its place, but don't let it take over your life.

Rather than being a consumer, become a producer. Rather than being a reader, become a writer. Sharpen your tools by doing not by seeing.
It's so easy to keep scrolling - but stop it and start writing! Writing will make you a better developer and a happier individual. It's happier to give rather than to receive.

If you start writing, it will make you stand out from the crowd. Even if you write poorly at the beginning, you won't be in the same position in 1 month from now or in a year from now. You'll be better. And you'll be happier. Your writing will attract and your content will make people want to work with you and get to know you.

So stop being just a reader and become a writer! Get off your read-only mode and start putting content out there. And you'll be better off!

Building a DataGrid with the right tools

Radu Brehar👨‍💻 — Wed, 04 Oct 2023 20:59:18 +0000

Building for the browser has historically been very tedious. In the old days you had to resort to all sorts of hacks for getting the right layout - anyone remembers conditional comments targeting IE6-9? 😅

Yeah, we don't miss those days either.

Things have evolved in the last few years, and the amount of goodies JS/CSS/HTML/layout goodies we now take for granted is staggering. New CSS features like flex/grid/custom properties really make a difference. Also browser performance has improved a LOT, and today we can do things in the browser that were unthinkable just a few years ago.

However, not everything is easier now than it was back in the browser-war days. Handling all kinds of devices, managing changing dependencies, configuring build tools, choosing the right styling approach, proper E2E testing, keeping a small bundle size, CI pipelines, etc. are all things that can (and will) go wrong if you don't have the right tools.

In this article, we're sharing the tools we used to build the InfiniteTable React DataGrid

TypeScript

It's obvious today to just go with TypeScript, but a few years ago, it was not as obvious. We've been using TypeScript for quite a few years now, and we're very happy with it. We can never imagine going back to plain JS.

React

Building on top of React has given us an amazing component model that's very composable and easy to reason about - and the ecosystem is huge.

Read about our journey in the Why another DataGrid? blog post. Back when React was launching, many of our team members were writing DataGrids - either in vanilla JS or using some libraries (jQuery anyone? - we don't miss browser incompatibilities).

CSS Variables and Vanilla Extract

As a DataGrid Infinite Table is built on top of CSS variables - we're going all in with CSS variables. They have a few gotchas in very advanced cases, but all-in-all they're amazing - and especially for performance.

Infinite Table is not short of CSS variables it exposes - see the full list.

Using CSS variables/custom properties has been pivotal not only to the ease of theming, but also to the performance of the DataGrid.
Being able to change a CSS custom property on a single DOM element and then reuse it across many elements that are children of the first one is a huge performance win. Our DataGrid performance would not be the same without CSS variables.

Vanilla Extract

The single tool that has made our life a lot easier working with CSS is Vanilla Extract. If you're developing a component library, you should definitely use it! Not so much for simple & static apps - there are other styling solutions that are easier to use, like tailwindCSS. But for component libraries, Vanilla Extract is amazing!

Did we mention it's amazing? 😅
The fact that you can use TypeScript with it, can use "Find All References", see where everything is used is a huge win. You're not writing readonly CSS anymore - because that tends to be the case with most CSS. People are afraid to change it or remove old CSS code, just in case those rules are still being used or referenced somehow. This way, CSS only grows with time, and this is a code smell.

With Vanilla Extract, you get to forget about that. You know what's being used and what's not.

Also, hashing class names to avoid collisions is nice - and something now very common in the modern JS ecosystem. It all started with CSS modules, and now it's everywhere, Vanilla Extract included.

Other great features we use extensively are:

public facing CSS variables - their names are stable
private CSS variables - their names are hashed
sharing CSS values with the TS codebase is a dream come true.
Vanilla Extract recipes - generating and applying CSS classes based on a combination of properties. It's enough that you have 2-3 properties, each with a few values, and managing their combinations can be a pain. Vanilla Extract recipes manage this in a very elegant way.

End-to-end testing with Playwright and NextJS

Remember the days of Selenium? All those flaky tests, the slow execution, the hard to debug issues? They're gone!

Playwright all the way! 300+ tests and going strong! Yes, you read that right! We have more than 300 tests making sure the all the DataGrid features are working as expected. Sorting, filtering, row grouping, column groups, pivoting, aggregations, lazy loading, live pagination, keyboard navigation, cell and row selection, theming - they're all tested! And we're not talking about unit tests, but end-to-end tests. We're testing the DataGrid in the browser, with real data just like real users would.

Playwright is an amazing tool, but we're not using it standalone. Paired with a NextJS app, with file-system based routing, we've created files/routes for each functionality. Each NextJS file in turn has a Playwright test file with the same name, but a different extension.

This has the benefit that it's always very obvious which test is running against which page. The test and the route always have the same file name, just the extension is different. The test source-code doesn't explicitly contain code that navigates to a specific page, all this is done under the hood, using this simple convention.

This way, we have a very clear separation of concerns, and it's very easy to add new tests. We just create a new file in the pages folder, and a new test file sibling to it. Another amazing benefit is that we can start the NextJS app and point our browser to whatever page we want to see or debug and it's there. We can very easily do the actions the test is doing and see if we get the expected results. This is a huge win for debugging.

A tailored state management

We've built a very simple yet highly effective state management solution for our DataGrid. It's built to make updating the internal state of the DataGrid as easy as possible - we want a simple API, with clear actions. Our actions map almost 1-to-1 to the DataGrid properties, which makes it very obvious to know who changed what.

We can't overstate how important it is to have a clear data flow through the DataGrid. This is because the DataGrid is by far the most complex UI component you'll ever use (and we'll ever build). You can't possibly go beyond that - at least not in common business apps, where you have the normal UI controls you can expect, like inputs, buttons, dropdowns, etc. Just the ComboBox can come near the complexity of the DataGrid, but it's still far behind.

It's important to be able to tame all this complexity - otherwise it can slow down the development process and bring it to a halt, making it difficult to add new features or fix bugs. With our current model, even though the DataGrid grew in complexity and features, we never felt our velocity dropping! We enjoy that!

No dependencies

We're very proud of the fact that we have no dependencies in our DataGrid. When you install our package, you only install our package - and nothing else. Nothing that can go wrong due to version conflicts, missing dependencies, npm issues (remember left-pad?).

Yes, we still depend on packages in our dev process, but we're striving to keep that small as well. It's already complex enough to keep TS, React, NextJS, npm (with workspaces), aliases, esbuild, tsup, playwright all working together in harmony. But we've got through it, and we're very happy with the result. It was worth it!

Separating concerns

We've separated our DataGrid into 2 main parts:

the <DataSource /> component - handles data loading and processing
the <InfiniteTable /> component - handles the rendering

This was a brilliant idea! It's new? No! It's not our invention, but we're happy we decided to apply it.

It adds a better separation between the two big parts of the DataGrid. This also helps tame some of the complexity, while adding clarity to the codebase. It's easier to reason about the code when you know that the <DataSource /> component is responsible for data loading and processing, while the <InfiniteTable /> component is ONLY responsible for rendering.

Conclusion

We're not sorry for choosing any of the above tools or approaches when building the InfiniteTable DataGrid component.

Our developer velocity is high, and we're able to add new features and fix bugs at a fast pace. We're happy with the result and we're confident that we'll be able to keep this pace in the future.

The right tools get the right job done! They make a lot easier. Looking back, we only regret we didn't have those tools 5 years ago - but hey, things are moving in the right direction, and we're happy to be part of this journey.

What are your tools for developer productivity?

Staying focused in a distracted world

Radu Brehar👨‍💻 — Wed, 08 Feb 2023 13:45:58 +0000

What happens when you stay focused on a problem for more than 10 years?

✅ you understand the problem well enough to know there's no easy solution
✅ you come up with multiple iterations, each better than previous
✅ you see many solutions rising and almost as many failing to solve the problem
✅ you get to sharpen your tools and your abilities like none other
✅ you finally deliver the right product 🛳

This has been my experience at infinite-table.com

Filtering Data with Infinite Table for React

Radu Brehar👨‍💻 — Fri, 27 Jan 2023 13:06:39 +0000

Why use Infinite Table filters?

1️⃣ Narrow down your data with your own filter types and operators

2️⃣ Works both client-side and server-side

3️⃣ Easy customization of filters and filter editors

4️⃣ Optimized for performance

5️⃣ Easy to use across multiple columns

Filters were, by far, the most requested feature to add to Infinite Table after our initial launch.

The recently-released version 1.1.0 of Infinite Table for React introduces support for column filters, which work both client-side and server-side.

In order to enable filtering - specify the defaultFilterValue property on the <DataSource /> component, as shown below

<DataSource<Developer>
  data={/* ... */}
  primaryKey="id"
  defaultFilterValue={[]}
>
  <InfiniteTable<Developer>
    columns={columns}
  />
</DataSource>

This configures the <DataSource /> component with an empty array of filters; columns will pick this up and each will display a filter editor in the column header.

Of course, you can define some initial filters:

defaultFilterValue={[
  {
    field: 'age',
    filter: {
      type: 'number',
      operator: 'gt',
      value: 40
    } 
  }
]}

You can see how all of this looks like when we put it all together in the examples below.

Local and Remote Filtering

Because the <DataSource /> data prop is a function that returns a Promise with remote data, the filtering will happen server-side by default.

When using remote filtering, it's your responsability to send the DataSource filterValue to the backend (you get this object as a parameter in your data function). This value includes for each column the value in the filter editor, the column filter type and the operator in use. In this case, the frontend and the backend need to agree on the operator names and what each one means.

Data reloads when filters change

Whenever filters change, when remote filtering is configured, the data function prop is called again, with an object that has the filterValue correctly set to the current filters (together with sortInfo and other data-related props like groupBy, etc).

However, we can use the filterMode to force client-side filtering:

<DataSource<Developer>
  filterMode="local"
  filterDelay={0}
/>

We also specify the filterDelay=0 in order to perform filtering immediately, without debouncing and batching filter changes, for a quicker response ⚡️ 🏎

Using local filtering

Even if your data is loaded from a remote source, using filterMode="local" will perform all filtering on the client-side - so you don't need to send the filterValue to the server in your data function.

Defining Filter Types and Custom Filter Editors

Currently there are 2 filter types available in Infinite Table:

string
number

Conceptually, you can think of filter types similar to data types - generally if two columns will have the same data type, they will display the same filter.

Each filter type supports a number of operators and each operator has a name and can define it's own filtering function, which will be used when local filtering is used.

The example above, besides showing how to define a custom filter type, also shows how to define a custom filter editor.

Providing a Custom Filter Editor

For defining a custom filter editor to be used in a filter type, we need to write a new React component that uses the useInfiniteColumnFilterEditor hook.


import { useInfiniteColumnFilterEditor } from '@infinite-table/infinite-react'

export function BoolFilterEditor() {
  const { value, setValue } = useInfiniteColumnFilterEditor<Developer>();
  return <>
    {/* ... */}
  </>
}

This custom hook allows you to get the current value of the filter and also to retrieve the setValue function that we need to call when we want to update filtering.

Read more about this in the docs - how to provide a custom editor.

Customise Filterable Columns and Filter Icons

Maybe you don't want all your columns to be filterable.

For controlling which columns are filterable and which are not, use the column.defaultFilterable property.

This overrides the global columnDefaultFilterable prop.

We have also made it easy for you to customize the filter icon that is displayed in the column header.

You change the filter icon by using the columns.renderFilterIcon prop - for full control, it's being called even when the column is not filtered, but you have a filtered property on the argument the function is called with.

In the example above, the salary column is configured to render no filter icon, but the header is customized to be bolded when the column is filtered.

Ready for Your Challenge!

We listened to your requests for advanced filtering.

And we believe that we've come up with something that's really powerful and customizable.

Now it's your turn to try it out and show us what you can build with it! 🚀

If you have any questions, feel free to reach out to us on Twitter, in the GitHub Discussions or in the comments below!

Make sure you try out filtering in Infinite Table for yourself (and consult our extensive docs if required).

📣 Infinite Table is Here 🎉

Radu Brehar👨‍💻 — Mon, 16 Jan 2023 09:35:45 +0000

Why use Infinite Table?

1️⃣ seriously fast

2️⃣ no empty or white rows while scrolling

3️⃣ packed with features

4️⃣ built from the ground up for React

5️⃣ clear, concise and easily composable props & API

We think you'll love Infinite Table.

This is the DataGrid we would have loved to use more than 15 years ago when we started working with tables in the browser.

And now it's finally here 🎉.

Built from the Ground Up with React & TypeScript

React all the Way

Infinite Table feels native to React, not as a after-thought, but built with React fully in mind.

It's declarative all the way and exposes everything as props, both controlled and uncontrolled.

If you don't like the default behavior of a prop, use the controlled version and implement your own logic and handling - see for example the following props related to column order:

columnOrder - controlled property for managing order of columns
defaultColumnOrder - uncontrolled version of the above
onColumnOrderChange - callback prop for notifications and for updating controlled column order

Fully Controlled

React introduced controlled components to the wider community and we've been using them for years.

It's where the power of React lies - giving the developer the flexibility to fully control (when needed) every input point of an app or component.

All the props which Infinite Table exposes, have both controlled and uncontrolled versions. This allows you to start using the component very quickly and without much effort, but also with the all-important flexibility to fully control the component when needed, as your app grows and you need more control over the DataGrid.

TypeScript & Generic Components

Infinite Table is also built with TypeScript, giving you all the benefits of a great type system.

In addition, the exposed components are exported as generic components, so you can specify the type of the data you're working with, for improved type safety.

import { InfiniteTable, DataSource } from '@infinite-table/infinite-react'

type Person = { id: number, name: string, age: number}

const data: Person[] = [
  { id: 1, name: 'John', age: 25 },
  //...
];
const columns = {
  id: { field: 'id' },
  name: { field: 'name' },
}

// ready to render
<DataSource<Person> data={data} primaryKey="id">
  <InfiniteTable<Person> columns={columns} />
</DataSource>

Why Use Infinite Table, cont.

Fast - virtualization

Infinite Table is fast by leveraging virtualization both vertically (for rows) and horizontally (for columns).

This means DOM nodes are created only for the visible cells, thus reducing the number of DOM nodes and associated memory strain and improving performance.

No white space while scrolling - clever layout & rendering

In addition to virtualization, we use clever layout & rendering techniques to avoid white space while scrolling.

When you scroll, the table will not show any empty rows or white space - no matter how fast you're scrolling!

We think this is one of the features that sets us apart from other components.

We've spent a lot of time and effort making sure no whitespace is visible while scrolling the table.

Batteries Included

We want you to be productive immediately and stop worrying about the basics. Infinite Table comes with a lot of features out of the box, so you can focus on the important stuff.

It helps you display huge datasets and get the most out of your data by providing you the right tools to enjoy these features:

sorting
row grouping - both server-side and client-side
pivoting - both server-side and client-side
aggregations
live pagination
lazy loading
keyboard navigation
fixed and flexible columns
column grouping
theming
... and many others

Infinite Table is built for companies and individuals who want to ship — faster 🏎!

(Almost) No External Dependencies

We've implemented everything from scratch and only directly depend on 2 packages (we'll probably get rid of them as well in the future) - all our dependecy graph totals a mere 3 packages.

We've reduced external dependencies for 2 main reasons:

avoid security issues with dependencies (or dependencies of dependencies...you know it) - remember left-pad?
keep the bundle size small

Composable API - with a small surface

When building a component of this scale, there are two major opposing forces:

adding functionality
keeping the component (and the API) simple

We're continually trying to reconcile both with Infinite Table, so we've built everything with composition in mind.

A practical example of composition is favouring function props instead of boolean flags or objects. Why implement a feature under a boolean flag or a static object when you can expose a functionality via a function prop? The function prop can be used to handle more cases than any boolean flag could ever handle!

A good example of composability is the groupColumn prop which controls the columns that are generated for grouping.

It can be either a column object or a function:

when it's a column object, it makes the table render a single column for grouping (as if groupRenderStrategy was set to "single-column")
when it's a function, it behaves like groupRenderStrategy is set to "multi-column" and it's being called for each of the generated columns.

<InfiniteTable 
  //...
  groupColumn= {{
    header: 'Groups'
  }}
/>

<InfiniteTable 
  //...
  groupColumn={() => {
    // this allows you to affect all generated group columns in a single place
    // especially useful when the generated columns are dynamic or generated via a pivot
    return {...}
  }}
/>

We've learned from our experience with other DataGrid components that the more features you add, the more complex your API becomes. So we tried to keep the API surface as small as possible, while still offering a rich set of declarative props as building blocks that can be composed to accomplish more complex functionalities.

Built for the community, available on NPM

We're thrilled to share Infinite Table with the world.

We wanted to make it very easy for everyone to get started with it, so all you require is just an npm install:

npm i @infinite-table/infinite-react

The component will show a footer with a Powered by Infinite Table link displayed. However, all the functionalities are still available and fully working. So if you keep the link visible, you can use the component for free in any setup!

Although you can use Infinite Table for free, we encourage you to purchase a license - buying a license will remove the footer link. This will help us keep delivering new features and improvements to the component and support you and your team going forward!