Colors are auto-generated based on the owner’s name (string). This is nice because it’s lightweight, but we should allow overriding the default via the team config object.

Currently, a Planner chart grows as needed to show all of the rows. This works well for small plans but large ones can get very tall (taller than the viewport). We should support a max-height prop and vertical panning for the overflow.

Ongoing tasks are currently shown as a semi-transparent bar with small chunks filled in:

The idea was to demonstrate that there's some rough amount of work (the combined size of the solid chunks) but that it was spread throughout the remainder of the plan.

I don't think the visualization works that well though. For that matter, I don't think that using the input stop date to infer how big the chunks should be works that well either. Conceptually, an ongoing task might not run until the end of the plan.

I propose changing this type to remove the concept of "duration" (the solid chunks) and instead just render a striped line that respects the stop date. This can indicate an ongoing task that's a fuzzy level of effort. (If a more solid level of effort is required, arguably, the task should be defined as several regular tasks and slotted in somewhere.

Includes need for in-data length units, which I wish were named durations. I'd be happy to take a hack at this. Should be able to support data inputs like:

createTask({
  id: "mile",
  name: "Bar",
  month: 2,
  length: 3d,
  dependency: "m-dep",
  owner: "susan",
});
createTask({
  name: "Foo",
  month: 2,
  length: 1w,
  isOngoing: true,
  owner: "team",
});
createTask({
  name: "Baz",
  month: 2,
  length: 3m,
  isOngoing: true,
  owner: "team",
});

There's a slight overflow happening in case of ongoing tasks (reproducible in the dummy initial data itself)

I was looking at the implementation and was wondering the possible reason for chunkWidth as follows

const chunkWidth =
      (task.duration * unitWidth) / (MONTHS.length - task.start);

If we change the denominator to 4 then it starts fitting perfectly.

const chunkWidth = (task.duration * unitWidth) / (4);

I was also wondering why you had added Math.min check while drawing the rect. Is it to account for the fact that last month's width may not be equal to unitWidth because we do Math.floor in determining unitWidth?

I was also looking at the implementation and found the sorting logic a little complicated to follow along. Instead of looping through all the tasks for a dependent task and then sorting them in-place via splicing (mutating props too), can't we use the following logic:

1. Loop through all the tasks and maintain `idToTaskMap` and `dependenciesMap`.
2. Initialise a new empty array called `sortedTasks`.
3. Filter out all the parent level tasks out of all tasks and then for each of those parent task, push the parent task itself in the `sortedTasks` first and then  if `dependenciesMap.get(task)?.length` then put all the dependent tasks in `sortedTasks` after sorting them.

In code it would translate to something like this:

    const sortedTasks = [];

    const dependenciesMap = new Map();
    const idToTaskMap = new Map();

    tasks.forEach((task) => {
      idToTaskMap.set(task.id, task);

      if (task.dependency != null) {
        const dependencyId = task.dependency;
        const dependency = idToTaskMap.get(dependencyId);

        if (dependency == null) {
          console.warn(
            `Invalid dependency; no parent task found with id ${dependencyId}`
          );
        } else {
          if (!dependenciesMap.has(dependency)) {
            dependenciesMap.set(dependency, []);
          }
          dependenciesMap.get(dependency).push(idToTaskMap.get(task.id));
        }
      }
    });

    tasks
      .filter((task) => !task.dependency)
      .forEach((task) => {
        sortedTasks.push(task);
        const dependentTasks = dependenciesMap.get(task);
        if (dependentTasks?.length) {
          const sortedDependentTasks = [...dependentTasks].sort((a, b) => {
            if (a.start < b.start) return -1;
            if (a.start === b.start) {
              if (a.duration < b.duration) return -1;
              if (!a.isOngoing && b.isOngoing) return -1;
            }
            return 1;
          });
          sortedTasks.push(...sortedDependentTasks);
        }
      }, []);

Will be happy to open a PR incorporating either or both of the changes as per your suggestions. Thanks in advance!

Looks like ENV_HOST and NEXT_PUBLIC_VERCEL_URL are set incorrectly for https://plannerjs.dev/ leading to mixed content warning for favicons and invalid og:url.

Thank you for making this public btw. Awesome project 🎉

Hi bro, that's great ❤
i try to added new team metadata, when i changed the "name", i saw a error

i think it can be fix with "?." operator

src/utils/color.js => line 2

export function hexToRgb(hex) {
  if (hex?.length === 4) {

See this thread on Twitter for context:

API documentation can be found here:
https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering

We should validate this change after it's made using the following URLs:

• Twitter validator
• Facebook validator
• Generic validator

Needs to take width of avatar (including text only circle) into account

Appreciate you making this public. Good to see how you guys build React apps (from the view of the rest of us). Took me a minute to realize that "loosing focus" updates the data when I type in changes. No need (IMHO) to fix, but might be helpful to add a text note to that behavior.

would like to use the canvas ui to change the owner instead of using the json. easier when the json file is large.

It seems like Planner can generate plan-specific og:image images dynamically by rendering a Canvas on the server and then capturing a screenshot (using Puppeteer or Playwright) and returning that. Some related tweet threads:

• https://twitter.com/terrysahaidak/status/1478727805907214342
• https://twitter.com/MichaelDeBoey93/status/1478539507343441921
• https://twitter.com/anthonygarvan/status/1478512005275398148

Vercel's og-image repo might also be a nice starting point to fork:
https://github.com/vercel/og-image

This would be a nice upgrade from the current behavior which is to just return the following hard-coded og:image:

The URL on the View days example in the readme points to localhost.

Nice library, thanks !

Example

Assigning a CSS color keyword like black instead of #000000 to color throws error:

Expected Behavior

1. If color's value doesn't begin with a #, compare it to a dictionary of CSS colors.
2. If not in the dictionary, either throw error or use "transparent" (your choice).
3. If in the dictionary, use that keyword for the color.

Example

When planning shorter duration efforts over longer time periods (think weeks in months), the bars get condensed to the point of not being legible at a glance:

Expected behavior

It would be useful to see a monthly or weekly view with a "map" of the greater whole to one side.

Mural has a feature like this, as an example of what I'm describing:

Hi @bvaughn just wanted to stop by to say hi! and really love your work.

I would like to use the canvas instead of editing the json. this would make the initial planning easy.

Seems like "next/image" is doing something funky to external image URLs.

Example data set:
https://plannerjs.dev/?data=eyJ0YXNrcyI6W10sInRlYW0iOnsiYnJpYW4iOnsiYXZhdGFyIjoiaHR0cHM6Ly9hdmF0YXJzLmdpdGh1YnVzZXJjb250ZW50LmNvbS91LzI5NTk3IiwibmFtZSI6IkJyaWFuIn19fQ==

Based on the data, the image that should be requested is:

https://avatars.githubusercontent.com/u/29597

But the URL that's actually requested is:

https://plannerjs.dev/_next/image?url=https%3A%2F%2Favatars.githubusercontent.com%2Fu%2F29597&w=32&q=75

This will remove an unnecessarily initial render and be more readable anyway.