Frustrations found along the way of building the dog app

[oliviertassinari]

The app: https://master--toolpad.mui.com/_toolpad/app/cl1c2j0l512939zo6a43575en/editor/pages/cl27gc98v00003f69ideijta5
I have prefixed each of the pain points under two different categories: UX vs. DX

• UX (7): a generic notion, this is the kind of challenge that you would face working on a generic product, like Airbnb.
• DX (6): similar to UX, but you would need to imagine yourself as a developer to resonate with the usability pain.

My notes:

• DX: Having to create a connection to make a fetch call seems a bit overkill. I get the use cases to be able to create REST connections, e.g. to add basic auth headers or to differentiate between the staging and production environment. Maybe it would make sense to have a generic REST connection that would always be available for usage. So that it's only once you face a specific need that you use it. It would have saved me one action. Add default Rest datasource #364

• UX: I have created an API and left the view but now I'm confused. My URL is not persisted? I need to click on the UPDATE button. The challenge is that we don't want to auto-save mistakes in the URL. I would suggest we have a dialog to confirm abandoning the changes when trying to leave. It will help build muscle and learn to save the changes. This caught me multiple times, it's painful.

• DX: Would it be possible to apply post transformations on my query states? I get that I can apply this transformation when I bind the value to a prop or a component, but I feel that I could save one context shifting. Datafetching, serverside post-transformation #366

• UX: In the binding editor: It would be great for Cmd + S to save in the code editor views or the whole state cmd + S should save the document #254.
• UX: When I'm on the "Create a new MUI Studio Code Component" popup, why is the input already filled with "MyComponent"? If we really want to have a default value, I think that we could have the default value selected so we can more quickly type something new.

• DX: I wish I had a debugger somewhere to see all my states. I have created a Debugger component to help me. But in the end, I didn't really used it.

import * as React from "react";
import type { ComponentConfig } from "@mui/toolpad-core";

export interface DebugProps {
  msg: string;
  debug: string;
}

export const config: ComponentConfig<DebugProps> = {
  argTypes: {
    msg: {
      typeDef: { type: "object" },
    },
    debug: {
      typeDef: { type: "string" },
    },
  },
};

export default function Debug({ debug = "Debug", msg }: DebugProps) {
  console.log(debug, msg);
  return (
    <div style={{ width: 400, backgroundColor: "red", color: "white" }}>
      Debug
    </div>
  );
}

• UX: When I bind a property, I wish I could get a live preview of the new value. Since I don't have this, I press the update binding multiple times. Not great.

I even wonder if on hover we shouldn't have a popup to show the content of the variable. So not the type, the value

• DX: I have caught myself forgetting to create a queryState multiple times. What could work better is to make what we current call "queryState" an "API" and what we currently call "API" a "Query library". Datafetching: merge API+queryState #365
• UX: Sometimes, I wish I could resize the right-side panel. Make properties panel resizable #496
• DX: I feel that the JSON type is painful to use. Would it make sense to have a JavaScript object syntax everywhere instead? My main issue is that JSON is less forgiving. You forget a quote, add one more quote and it fails to parse. Use JSON5 to parse the content of the JSON editor #495
• DX: In the "Bind a property" view, it would be interesting to know the nature of the global variable. Is it a component or an API state? It could help more quickly navigate what's available. We might even want to group them. Show more info on global variables in binding editor #497

• DX: I have to handle the case when the data is loading manually. I have disabled the select components. I also had to add defensive logic:

getImage?.data?.message

• UX: We could have a proper Image component, there is an issue about it on the Material UI repository, maybe to use it as a source of inspiration or even for contribution Add Image component material-ui#22470

[Janpot]

All issues are either fixed or scoped down to individual github issues