wasp-lang / wasp

The fastest way to develop full-stack web apps with React & Node.js.
https://wasp-lang.dev
MIT License
13.8k stars 1.19k forks source link

Simplify Wasp TS config (TS SDK) syntax #2353

Open Martinsos opened 1 month ago

Martinsos commented 1 month ago

For now, we made Wasp TS config have the same syntax as Wasp DSL. But, it now becomes easier for us to iterate on the syntax, especially if we phase DSL out. So let's talk here about how we can improve it and collect ideas, so we can do it when the moment comes!

We can do changes on multiple levels:

  1. Add helper functions that come with Wasp TS config, that users can use as a shorthand.
  2. Adjust actual Wasp TS config syntax to be better, but then in the background be smart about translating that into AppSpec.hs (e.g. we can say that pages don't need a name anymore, but we will have to then, in the background, produce one still so we can turn it into AppSpec.hs because it requires names for each decl).
  3. Change AppSpec.hs itself. This is the way to go for more fundamental stuff (e.g. do declarations have names). This will also be more feasible if we drop DSL and have just TS config.

Natural progress can also be (1) -> (2) -> (3), meaning that we can try out new stuff in (1), then adapt (2) if that works, and finally push the change to (3). Or we can skip steps of course if that makes sense, but this way we can test things gradually.

Martinsos commented 1 month ago

Boilerplate when defining pages and routes

There is quite some boilerplate here, big part of it coming from part that is common for the rest of the config also, which is that declration names and import symbols are often very same or similar.

But, let's be specific for routes and pages.

Here is how I attempted to make my Wasp TS config more readable:

appPageWithRoute('Main',     '/',         '@src/client/MainPage.jsx',     { auth: true });
appPageWithRoute('Thoughts', '/thoughts', '@src/client/ThoughtsPage.jsx', { auth: true });
appPageWithRoute('Login',    '/login',    '@src/client/LoginPage.jsx');
appPageWithRoute('Signup',   '/signup',   '@src/client/SignupPage.jsx');

function appPageWithRoute(pageName: string, path: string, from: ExtImport['from'], config?: { auth: boolean }) {
  const page = app.page(pageName, {
    component: { importDefault: pageName, from },
    ...(config?.auth && { authRequired: config?.auth })
  });
  app.route(pageName + 'Route', { path, to: page });
}

I overdid it a bit, I don't think this should be normal API, because we need to be able to define routes on their own (route can point to other stuff than page, or at least it should be able to), and also positional arguments might not be the best, but it does go some way in the right direction I believe.

Here is what @vincanger did:

// Either pull the name from the const variable name, e.g. "MainPage"...
const MainPage = app.pageWithRoute({ 
    import: 'Main', 
    from: '@src/client/MainPage.jsx'
    route: '/',
    authRequired: true 
});

// ...or use the same name as the imported component
pp.pageWithRoute({ 
    import: 'MainPage', // Page name would default to MainPage, and route name to MainPageRoute
    from: '@src/client/MainPage.jsx'
    route: '/',
    authRequired: true 
});
Martinsos commented 1 month ago

Boilerplate caused by declaration names and imports

Big part of boilerplate right now is that you have to define declration names always, even though often they are not used anywhere, and also you have to provide names even for default imports (although we might phaes out default imports so in that case not a concern), and declaration names and import names are often really just the same thing. This goes for more or less all declarations. Names are important for pages though, because we reference them in some places (in routes at least).

infomiho commented 1 month ago

Route decl names are important for referencing them in the email auth provider setup. We can change this to be a plain string. e.g. emailVerification.clientRoute https://wasp-lang.dev/docs/auth/email#fields-in-the-email-dict