Closed asturur closed 1 year ago
Yesterday i prepared the code but i got stuck in one of those problem where our mixed import strategy makes now object undefined and i have no idea how to fixed. Working on it.
https://github.com/fabricjs/fabric.js/pull/8322
Ok this is a PR. Go with the negatives please, pointing out issues ( that are not cited already in the pr description )
please provide a version of react native
@ideaviewes it is out of scope for this thread. I suggest you open a dedicated discussion.
Hi, what's next for this? Is there a way to contribute? I've been rooting for Typescript integration since I've been using this. I noticed there were concerns about making cacheProperties static. If it's about getting the property using this, I think that might work with static, as long as there's not a non-static with the same name. If that idea isn't exciting, there's also creating a method that could be overridden by subclasses and each class would just return the static variable in its version.
I'm sorry for bumping into this adult conversation but I thought I might represent a voice of us little folk that: a) are enjoying Fabric and are hoping to utilise it more in the future, and b) are not coding ninjas and sometimes struggle with more advanced concepts of JS. I do hope that moving in whatever direction will not mean making using Fabric any less problematic for non-expert programmers like me and there will be enough examples and well written docs that it will be possible to use it without a need to hire a pro or rush to SO with every little issue. I've had this experience with D3 where it became somewhat harder and harder to use recently (but that might well be the little old brain of mine!). Thanks and good luck!
Just a minor thing, you can use ts-expect-error
instead of ts-ignore
. The difference is that ts-expect-error
won't compile if the next line is not a typescript error. That way, when the underlying issue is fixed, you will automatically notice that the issue is fixed and typing can be re-enabled for that line.
Hi everyone,
A year has passed since this ticket was opened.
Beta is out! Published last week, just in case anyone missed it. You can install it via
npm i fabric@beta
We migrated the entire codebase and made significant changes and fixes, see #8299 and the CHANGELOG. Most of the codebase is fully typed. Some complex modules remain in need of typing and perhaps more touch ups.
Building is done with rollup.
fabric has its own cli now so you can enter npm run cli -- -h
and continue from there.
You may experience stuff with consuming types and/or the build, submit an issue if you do. We are still figuring that out.
Repository docs have been updated as well to reflect v6 changes (README, CONTIBUTION etc.). More work is needed in this field. The website remains outdated. This will be the next major effort after we release v6. We will announce updates about that in the future.
Remember it is beta, things aren't final and may change (the entry point especially). Considering the scope of changes, regressions might surface. Also take into consideration a shift in the way fabric is used. Subclassing is now super easy (class is no. 1 citizen in v6) and there is no fabric namespace.
As always, contributions are welcome (either TS, website or anything else), see #8316. Ping one of us in an issue/discussion/PR so we can direct the efforts and give a hand or suggest a solution.
With T or without, but we are badly missing some types in v6. For example, BaseFabricObject, TEvent, ObjectEvents, etc.
@bladerunner2020 tracker issue #8868
Is there a new way to access the .fabric
property of a Canvas
element in the beta?
This
import {Canvas, Image} from 'fabric';
const canvas = new Canvas('certcanvas');
document.getElementById('certcanvas').fabric = canvas;
Image.fromURL('assets/img/cert.png', function(img) {
img.set({
lockMovementX: true,
lockMovementY: true,
selectable: false
});
img.scaleToHeight(566);
img.scaleToWidth(800);
canvas.add(img);
Doesn't seem to work for me…
Oops, just catching up on the promise-ification of Image
and Textbox
… any links to some examples would be great.
fabric is now typed - use that. I wouldn't wait for the website, unless you join the effort and give a hand.
For the greater community:
We want to wrap up the TS migration and we need help.
Contributions are needed!
Current task is to type the remaining files and address TS errors.
Contributors can search for files with @ts-nocheck
and get to work.
Open a draft PR with the title chore(TS): [SCOPE]
once you get started stating which files you wish to address so people don't work on the same thing.
Then when you are done, move it out of the draft state and review it and then one of us will review as well.
Be sure to check for open PRs before you start working.
If someone wishes to do it all go ahead.
Thanks!
Originally posted by @ShaMan123 in https://github.com/fabricjs/fabric.js/issues/8299#issuecomment-1644418966
Ok we are ready to close this.
The last ts-nocheck
have been removed, now the library is fully typed.
We are doing a last check up of the api we changed during this year of migrations and we are releasing a stable 6.0. We will handle missing exported types as patches ( 6.0.x ) but we will try to catch all the missing exports before.
Eraser brush is not ready yet and is going to be added as the next thing. We are also working on docs and we will try to update all the introductions to fabricJS on the website with modern content that make sense Some of them have been written in 2011 and are outadated.
Hello everyone!
FabricJS is nearly 12 years old.
The library has still its place around the internet, is good for many things, is never perfect, but i know that for who approach rich canvas based interactive apps, this is a nice piece of software to leverage.
While our main fault are still lack of great docs and updated and clarifying examples, now also the javascript code looks like a lot obsolete.
There are things we could leverage like Promises, default value for arguments, fat arrow for loops and readibility, native classes, proper getters and setters.
We would like to take the occasion to revisit the shape of the codebase to something more modern. This would include proably a bundler, proper import statements instead of a single file that gets built like lego blocks, maybe tree shaking for who import just what he wants to import.
This would make the custom built unnecessary, using other libraries easier including touch interactions.
So a move to es201X is coming anyway.
The question is if we want to add type descriptors or if we want to make a TS migration right away.
The benefits of consuming TS are clear to me, the benefit of writing typescript a little less, i'm not a great fan and also i m not great a TS. Is very easy to use TS in the wrong way and produce subpar results.
We are open to suggestions and understand what is the best way to make everyone happy. external type definition in form of d.ts files are a good middle way if there is a way to enforce correctness at build time. A new lint profile is required. A new build tool too. Legacy JS support is not going away. A bundler will produce the correct code for older browsers. But probably IE11 is out of the game anyway. I would love to have 2 builds, a legacy one and a modern one ( the classic last 2 versions of each browser )
So which are your reason to list TS on the pro/cons of this change? I understand you may not like TS. that is fine. I don't like it either. But if is terse, with types out of the way, and a transpiled build is available, what is your main point against or for it?