You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently (please correct me if I'm wrong), the only way to include JS syntax inside an MDX file is to preface that code with either the import or export keywords - and as such, to use their functionality. What if we don't need that functionality?
If I want to declare variables in my MDX, I have to use export const = <my_variable>, this is true even when I don't want to / shouldn't export that variable.
My typical usecase for local (to the file) variables would be to declare props that I can later pass as props, or to define JSX components (that wouldn't be used outside of the file).
Suggestion
Why not include an extra keyword that can preface JS statements / blocks? I would suggest embed or inline.
This is what that might look like;
// NOTE: This is exported.exportconstExportedComponent=({ text })=><p>{text}</p>// NOTE: This is local.embedconstLocalComponent=({ text })=><p>{text}</p>
I've taken a quick look at the implementation of remark-mdx, and it looks like this would be quite trivial to add there... the compiler would just need a new handler, which would be no different to the import or export handlers (although it would strip the embed || inline keyword) - happy to PR.
Alternatives
The excellent idea of inlining fenced code blocks (proposed in #701) could do the same thing (allowing non exported JS statements) - I'd love it if both were implemented and the user was able to choose.
The text was updated successfully, but these errors were encountered:
axdg
changed the title
New keyword for non-exported ES sytax
New keyword for non-exported ES syntax
Aug 6, 2019
Rather than introducing a new keyword I kind of lean towards what's proposed in #701 since it introduces one more bit of API surface area that can be a viable escape hatch for all of these (understandable) needs for additional JS syntax.
Though, for something like variable declarations this won't exactly work as proposed in #701 since we'd have to differentiate where the contents of the inline/eval-ed code block would be embedded since imports/exports/variable declarations would need to live outside the component while JSX syntax would need to be embedded where it is.
I'm going to go ahead and close this since #701 and an RFC for local vars (#1046) has been opened. The latter has been directly inspired by this issue, thank you for opening @axdg!
Problem
Currently (please correct me if I'm wrong), the only way to include JS syntax inside an MDX file is to preface that code with either the
import
orexport
keywords - and as such, to use their functionality. What if we don't need that functionality?If I want to declare variables in my MDX, I have to use
export const = <my_variable>
, this is true even when I don't want to / shouldn'texport
that variable.My typical usecase for local (to the file) variables would be to declare props that I can later pass as
props
, or to define JSX components (that wouldn't be used outside of the file).Suggestion
Why not include an extra keyword that can preface JS statements / blocks? I would suggest
embed
orinline
.This is what that might look like;
I've taken a quick look at the implementation of
remark-mdx
, and it looks like this would be quite trivial to add there... thecompiler
would just need a newhandler
, which would be no different to theimport
orexport
handlers (although it would strip theembed || inline
keyword) - happy to PR.Alternatives
The excellent idea of inlining fenced code blocks (proposed in #701) could do the same thing (allowing non
export
ed JS statements) - I'd love it if both were implemented and the user was able to choose.The text was updated successfully, but these errors were encountered: