Replies: 7 comments 7 replies
-
Yes. E.g. If you go to the Layout Video Proof Array under "Family Comparison" you can add a new layer using "+" and then change the "Family". |
Beta Was this translation helpful? Give feedback.
-
Can you please elaborate? I'm not sure why it is needed. Also note, we're going to switch to use Vite soon as implemented in #32 this makes usage of TypeScript and also jsx possible. Probably there's also a way to import files as text. I can speed up the Vite integration if you would prefer it. The #32 PR uses an existing module to integrate the POC for the React bridge, that part should not be as it in the main branch. |
Beta Was this translation helpful? Give feedback.
-
|
Editing HTML inside JS strings is not ideal. The developer doesn't get syntax highlighting, autocomplete, autoclosing tags, etc. |
Beta Was this translation helpful? Give feedback.
-
|
The HTML template strings are rather short. When they are in separate files, I personally dislike the scattering of concerns (a lot) more than I would profit from the editor support. For longer HTML it may be shifting towards me benefiting from having the editor support. So far, the HTML template strings are so important to the code that loads them that I prefer having them directly where they are used, it's also quick and easy to override the templates e.g. in sub classes, but that's not done very often. I wonder if something with JSX could be utilized, because it will be available in the project soon due to the move to vite. JSX should have broad syntax highlighting support in editors. It would have to replace lines like this: |
Beta Was this translation helpful? Give feedback.
-
|
I made an experiment, the following is possible: File import {
_BaseComponent
} from './components/basics.mjs';
export class Example extends _BaseComponent {
constructor(widgetBus) {
super(widgetBus);
[this.node] = this._initTemplate();
this._insertElement(this.node);
}
_initTemplate() {
const h = this._domTool.h;
return [<h1>hello</h1>];
}
}It compiles to: import {
_BaseComponent
} from "/TypeRoof/lib/js/components/basics.mjs";
export class Example extends _BaseComponent {
constructor(widgetBus) {
super(widgetBus);
[this.node] = this._initTemplate();
this._insertElement(this.node);
}
_initTemplate() {
const h = this._domTool.h;
return /* @__PURE__ */ h("h1", null, "hello");
}
}I used the vite config: plugins: [
// ...
{ // custom typeroof jsx flavor
name: 'tr.jsx',
enforce: 'pre', // Runs this plugin before other transformations
async transform(code, id) {
if (!id.match(/.*\.tr\.jsx$/))
return null
console.log('id', id, 'MATCHED!');
const result = await transformWithEsbuild(code, id, {
loader: 'jsx',
jsxFactory: 'h', // Explicitly sets 'h' as the JSX factory
jsxFragment: 'Fragment',
sourcemap: true,
// Add other esbuild options here if needed, like target
});
// Return the transformed code
return {
code: result.code,
map: result.map,
};
},
},
],and added to _h (tagname, attr = {}, ...children){
// Create the DOM element
return this.createElement(tagname, attr, children);
}
get h(){
return this._h.bind(this);
} |
Beta Was this translation helpful? Give feedback.
-
|
JSX is a good solution, it solves both issues of code separation and HTML editing. My one suggestion would be to use a file extension like |
Beta Was this translation helpful? Give feedback.
-
Yes, documentation of these aspects is required indeed! I can answer questions in discussions and we can tailor them to become general documentation. Maybe ask specific questions as new discussions and I will give my best to elaborate. Follow up questions can be answered in further discussions etc. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I can create new discussions for this. |
Beta Was this translation helpful? Give feedback.
-
I'd like to collect future plans I have in my mind before making big changes here. I wouldn't like to have a big refactoring here before we didn't solve a questions that's looming on the horizon. Probably, your 6. Expand the technical overview in the documentation should also include a "future perspective" which would help a lot to assess the current state as well. That said, general improvements on the CSS and markup shouldn't be a problem to do now, and getting a concept into the handling of styles would also be appreciated by me.
These two would be definitely nice.
I’d like to discuss this further before making a decision. |
Beta Was this translation helpful? Give feedback.
-
|
This is one area that I'm highly interested in working on. We can split the UI/UX improvement project into multiple phases, to ensure minimal interference with the application's internal logic. Here's an initial idea for a roadmap: Phase 1: Addressing cross-browser UI inconsistencies Phase 2: Improving visual hierarchy Phase 3: Rearranging UI elements Phase 4: Changing user flows |
Beta Was this translation helpful? Give feedback.
-
A List of missing features would definitely be nice to have. There are features that are missing and have been requested by @dberlow the most prominent in my mind is the design space location label, in light blue, in the legacy app. In the Video Proof layouts, it's located at the top right corner. In the Type Tools layouts it's an option under "Variations -> Show parameters". I expect each layout will require a custom manifestation to this but, I'd still try to create an underlying shared approach. |
Beta Was this translation helpful? Give feedback.
-
For the most part they are pretty separate I believe. We could add a "legacy-" prefix to directories or files that are clearly only legacy. e.g. "lib/js/layouts" could become "lib/js/legacy-layouts" There are also shared files however, e.g. |
Beta Was this translation helpful? Give feedback.
-
|
Another idea I had while working on this demo last week is to have an API to create a "Stages and Actors" animation instead of using the UI to do it. |
Beta Was this translation helpful? Give feedback.
-
|
We are also definitely interested in making better and improving existing UIs. A drawbot-like mode could be interesting, I'm not sure what kind of integration for this would be ideal. I feel like a bit more than drawbot would do would be great, maybe to be able to create partial macros that then include with the rest of the App. A public API to get/send json/state-data could be exposed using |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Based on what I've seen so far, here are some ideas for contributions that I could make to the project and also some suggestions for improvements.
@graphicore @dberlow Let me know what you guys think.
Contribution ideas
1. UI/UX improvements
2. Implement Gustavo's proofing tool in Shell
Gustavo's tool requires loading and interacting with 2 variables fonts at the same time. Is this possible with TypeRoof?
3. Port Legacy features to Shell
Is there a list of missing/pending features that needs to be implemented in Shell? If there isn't, I can help creating it.
Suggestions for improvements
4. Have separate folders for Legacy and Shell source files
It would make navigating the codebase easier.
5. Allow loading templates from the HTML file
Implement an option that allows loading templates from the HTML file as an alternative to JS strings containing HTML code. I can work on this later.
6. Expand the technical overview in the documentation
One thing that would make the existing documentation more valuable would be expanding this paragraph.
How does TypeRoof simplify font loading and state sharing? What technical problems does TypeRoof solve? Answering these questions would help developers understand why they should use TypeRoof.
Based on this discussion, it seems TypeRoof does things behind the scenes which aren't noticeable by just using the application. It would be really valuable if this was explained in further detail.
Beta Was this translation helpful? Give feedback.
All reactions