Hey hey, what's the scoop on the v2 incompatible components? They all look like they'd be great to use. May be worth rallying up some community effort to get them v2 ready if the original authors don't have the capacity.
Many of the components have open PRs to move to v2, for example, https://github.com/JureSotosek/ink-divider/pull/3 But if the author doesn't respond, there's not much we can do. If it's an important component, we can fork it and maintain it. Otherwise, we'll just remove it from the list if the original author never responds.
Help welcome if there are incompatible components without an open PR to move to v2.
Just opened a PR for ink-table v2 migration. I miraculously got it to work a couple of weeks ago, but didn't understand the code well enough to know if I fixed it _correctly_. All of the string building is hard to parse. 馃槄
Wanted to drop a couple of other notes:
It'd be great if there were a lot of examples that covered enough use cases that people could just take one and tweak it how they want to throw together a CLI quickly.
For interactive CLIs, it'd be great if there was some kind of simple state machine/routing implementation that people could use to map out the various states of their CLI. I started working on making ink-router into v2, but ended up just pulling the Route component out of react-router-dom and implementing my own. Would you want to go with the RR style for this, or try to come up with something else?
Finally, file system management. Does it make sense to have a lib that provides components or hooks that'd serve as wrappers around fs?
It'd be great if there were a lot of examples that covered enough use cases that people could just take one and tweak it how they want to throw together a CLI quickly.
For interactive CLIs, it'd be great if there was some kind of simple state machine/routing
Agree, which is why I'm building Pastel :) See https://twitter.com/vadimdemedes/status/1112507907642294272 for more info. Almost done with it, will release after Easter.
Finally, file system management. Does it make sense to have a lib that provides components or hooks that'd serve as wrappers around fs?
What would you need a wrapper for and why?
Yes, currently I'm working on some migration job for these incompatible components, but several of them were blocked by some issue.
For another hand, we need some standard for creating a Ink component, like this: https://github.com/vadimdemedes/ink/issues/177#issuecomment-477434052.
At last, I could help to review these present migration PRs.
For another hand, we need some standard for creating a Ink component, like this: #177 (comment).
Good idea, Ink v1 had Yeoman generators for that, but I decided to not use them for Ink v2. I'll create create-ink-app and create-ink-component instead, stay tuned!
Agree, which is why I'm building Pastel
Pastel sounds awesome! Was that in response to the routing part, though? My thoughts on routing relate to control flow when you're running a CLI command that requires branching logic.
Do you want to use thing?
> [Y/n] y
Give me a name for that thing:
> Thing!
or:
What do you want to do?
1. Create a foo
2. Create a bar
>
I always seem to want to build these complex types of CLIs. Maybe they're bad design, though, and a command based CLI pattern would be better.
What would you need a wrapper for and why?
I'm not sure if this would be useful or not, but, since we're building CLIs with React, I thought it may be nice to have a component wrapper for fetching files:
<FileProvider directory='./src'>
{ (files) => {
files.map(file => <File {...file} />
}
}
</FileProvider>
Ink-divider has been migrated to Ink 2.0 馃帀
I'm not sure if this would be useful or not, but, since we're building CLIs with React, I thought it may be nice to have a component wrapper for fetching files:
Hm, doesn't sound like a good idea to me, since they're literally wrappers around fs, but in JSX. Why not use fs directly?
I just made a new big text component based on figlet.js, as the original one seems to be not actively maintained. I'm writing it in TS and plan to add color themes support (porting the theme definitions by @AlexLakatos), so I didn't directly fork Kimoto's repo, and named it ink-ascii.
Created a PR #238 to add it in the README, if I may. 馃槃
I'm working on an independent export for the generate() function, it should be ready by Monday. So you could depend on the ascii-themes module, and use the generate function, without having to port the themes.
Most helpful comment
I just made a new big text component based on figlet.js, as the original one seems to be not actively maintained. I'm writing it in TS and plan to add color themes support (porting the theme definitions by @AlexLakatos), so I didn't directly fork Kimoto's repo, and named it
ink-ascii.Created a PR #238 to add it in the README, if I may. 馃槃