Comments (8)
What kind of errors do you think of?
I meant: If we only support extensionless imports, users will more often be correcting how they import things (than they would if we just supported everything).
I might not be objective, but this was never the point of confusion for me personally. Actually au contraire, I was confused when at some point working with node TS lib I needed to use .js extensions, whereas my files were in .ts
We had a misunderstanding here.
I didn't mean they'd be wondering "Why do I have import TS file with JS extension."
I meant they'd be wondering "Why do I have to import a JS/TS file without an extension when it does have it in reality.
I don't understand this at all 👀
Haha, no worries, the TS SDK is still in the works so it's normal you don't know the details. The basic idea is, once we implement the TS SDK, specifying files without extensions might be weirder than it is now. More specifically...
This
app.action('createTask', {
// Import without extension
fn: { name: 'createTask', file: 'actions' },
entities: [Task],
auth: true,
})
Might look stranger than this:
app.action('createTask', {
// Import without extension
fn: { name: 'createTask', file: 'actions.js' },
entities: [Task],
auth: true,
})
Since the field's name is file
, one would probably expect to be allowed to write the file's true name.
For example, in vite react app (or any other frameworks for that matter), you import your JS / JSX files with a simple file name (without extension) and assets such as PNG, Svgs etc - with extension.
Makes sense. Another thing to maybe consider is what happens when we introduce multiple languages. Extensions may com in handy then (but discussing this is probably looking too far into the future).
from wasp.
I'd vote for this kind of functionality at any time of the day I think
Yeah, I think we all agree there 😄
but I don't know how much this complicates things
This is precisely the problem - neither do I (yet), but this approach is what I meant when I said:
But ideally we'd come up with a plugin that imports stuff normally (this will help us with the LSP as well).
In any case, I'll be looking into it in the following weeks. Let's hope it's simple enough!
from wasp.
Let's discuss which extensions we want to allow in our Wasp file.
The reasonable options I'm aware of are:
- No extensions (
@src/queries
regardless of the file's true extension) - The file's true extension (
@src/queries.ts
forqueries.ts
,@src/queries.js
forqueries.js
, etc). - The file's "compiled extension" - This is relevant only for TS stuff (
@src/queries.js
forqueries.ts
, and@src/queries.jsx
forqueries.tsx
). - The file's "transpiled extension" - This is relevant only for "X" stuff (
@src/queries.js
forqueries.jsx
,@src/queries.ts
forqueries.tsx
) - Some combination of the above.
User feeback
Points raised by our users in Discord (thread):
- Either
1
(because it's simple) or2
(because it's explicit), but I prefer option1
- what about svgs for example? non-code files would be imported with file extensions though?
- I would prefer option 2, although 1 doesn't sound that bad either, but since non-code could potentially be imported, it could mean a lot to have the extension explicitly stated
So we should also consider how we want to handle Ext imports of non-js files (and if we'll ever have any).
My thoughts
I'm leaning towards either option 1
or option 2
, not both of them (our users seem to agree). I'll analyze this dilemma from option 1
's point of view.
PROS of alowing only @src/queries
(no extension)
- Users won't be tempted to have the same base file name with different extensions (which we don't support).
- Easier to swtich from
ts
tojs
(for users). - Fewer rules for LSP and mappings.
- Simpler to implement (requires a subset of functionalities that we'd need to implement to support more extensions)
CONS of alowing only @src/queries
(no extension)
- Reduced flexibility for our users, less robust. Users will run into ext import errors more frequently.
- Possibly confusing: "Why must I change the file name from
something.js
tosomething
whensomething.js
is its real name? - Might not play nicely with the TS SDK (especially if we name the appropriate field something like
fileName and it doesn't contain the actual file name). We could name it
module`, but that's possibly too technical. - What happens when we introduce non-code Ext imports?
Mapping procedure
In any case, these are all the possible mappings (ext import
-> SDK import string
):
@src/queries.jsx
->wasp/ext-src/queries.jsx
@src/queries.tsx
->wasp/ext-src/queries.jsx
@src/queries.js
->wasp/ext-src/queries.js
@src/queries.ts
->wasp/ext-src/queries.js
@src/queries
-> Apply the mapping procedure to the real file name
from wasp.
Reduced flexibility for our users, less robust. Users will run into ext import errors more frequently.
What kind of errors do you think of?
Possibly confusing: "Why must I change the file name from something.js to something when something.js is its real name?
I might not be objective, but this was never the point of confusion for me personally. Actually au contraire, I was confused when at some point working with node TS lib I needed to use .js
extensions, whereas my files were in .ts
. I just accepted it and made my peace with it, but the fact is - this is something you don't do when building react projects (bundlers handle all of this for you).
Might not play nicely with the TS SDK (especially if we name the appropriate field something like fileName and it doesn't contain the actual file name). We could name it module`, but that's possibly too technical.
I don't understand this at all 👀
Maybe another example / use case can make it through my thick skull.
What happens when we introduce non-code Ext imports?
The same thing as what most modern bundlers do - handle it "internally" and bundle it. For example, in vite react app (or any other frameworks for that matter), you import your JS / JSX files with a simple file name (without extension) and assets such as PNG, Svgs etc - with extension. I think this is a "expected" behaviour by majority (..I dare speaking for majority...)
from wasp.
@infomiho suggested (assuming we're sticking with the object ext import syntax) we do something like this:
app.action('createTask', {
// Mind the key name changes
fn: { import: 'createTask', from: 'actions' },
entities: [Task],
auth: true,
})
But ideally we'd come up with a plugin that imports stuff normally (this will help us with the LSP as well).
from wasp.
@infomiho suggested (assuming we're sticking with the object ext import syntax) we do something like this:
app.action('createTask', { // Mind the key name changes fn: { import: 'createTask', from: 'actions' }, entities: [Task], auth: true, })But ideally we'd come up with a plugin that imports stuff normally (this will help us with the LSP as well).
crazy thought probably, but what about instead of
fn: { import: 'createTask', from: 'actions' },
you just import the function and pass it in, like
import { createTask } from "@/actions";
app.action('createTask', {
// Mind the key name changes
fn: createTask,
entities: [Task],
auth: true,
})
this removes posslbe ambiguity of how to call files + it is a clear and predictable by devs way.
but I don't know how much this complicates things, but I'd vote for this kind of functionality at any time of the day I think
from wasp.
{ import: '...', from: '...' }
is perfectly fine for now I think, and has no issues with extensions, as you said! We can try to add more fancier stuff on top later, this will need to be the founbdation in any case.
What did Discord vote say, from what I got most people are for "no extension" option?
from wasp.
{ import: '...', from: '...' } is perfectly fine for now I think, and has no issues with extensions, as you said!
It has issues with differentiating between named and default imports, but I forgot to mention it. Any ideas there?
from wasp.
Related Issues (20)
- Add support for multiple servers
- `useQuery` doesn't handle errors thrown from wasp operation HOT 1
- Allow more complex CORS setups HOT 1
- wrong url after deployment HOT 2
- ERR_MODULE_NOT_FOUND on build (reproducible with fresh install) HOT 1
- Refactor database engine definitions HOT 2
- Unit test all of our framework code HOT 1
- Implement proper import mappings in SDK generator
- Deployment issue, project works on dev, deployed behind apache there is an odd "Hello world" route HOT 1
- `wasp deps` command doesn't output the SDK deps HOT 1
- Expose PgBoss instance as part of public API
- Rename "client unit tests" to something more appropriate HOT 1
- Server URL gets reset on the client in new deployments on Fly HOT 1
- [By end of Sep] Update Wasp AI GPT models
- Make it clear what is the best option for deploying the Wasp app for free
- Implement TS SDK npm package libraries
- Update Tanstack Query to the latest version
- Update React router to the latest version
- Implement a POC execution system for the TS SDK
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wasp.