search

znjameswu / flutter_math

Math rendering and editing in pure Flutter.
https://znjameswu.github.io/flutter_math_demo/
Apache License 2.0
123 stars 52 forks source link

A couple of comments #26

Closed modulovalue closed 3 years ago

modulovalue commented 3 years ago

Hi @znjameswu

  1. Have you considered splitting flutter_math into 2 distinct packages where one doesn't depend on flutter and with the other containing all the flutter related logic? Besides the obvious benefits, this would allow the tests on the dart side to make use of darts reflection capabilities. They might not be needed now, but this is a big project and that will come in handy in the future. It will be a lot harder to do that split in the future.

  2. For 1 to be possible i.e. to take the widget building logic out of the ast nodes, you would need to introduce an ast visitor (e.g. https://github.com/dart-lang/sdk/blob/master/pkg/analyzer/lib/dart/ast/visitor.dart). Visitors are actually essential for many other concepts that I'm sure will come up as flutter_math matures. This would also make flutter_math much more maintainable as functionality could be split up into separate visitors. I would appreciate a comment if you intentionally decided not to do that.

  3. Have you considered reaching out to simpleclub? AFAIK catex only happened because of their financial support. Perhaps they would be interested in supporting flutter_math as well. Nonetheless, you should consider adding a note to the readme that you are willing to maintain flutter_math over the long term (if you are) and that you are willing to commercially support flutter_math (or something along those lines). This has the potential to become a very valuable project to a lot of companies.

znjameswu commented 3 years ago

Thank you for the comment. They are very helpful! Here is my thought on this.

Package splitting

I have considered splitting into smaller packages. This package starts out as a KaTeX port and gradually adding stuff, hence now. However I have some concerns.

As a natural logic, it is best to split it into AST, TeX parser, TeX encoder, UnicodeMath parser, etc. However, each widget variant still needs a particular combination of these packages. Will they creat more-than-necessary amount of packages? Any good thoughts?

Decoupling building logic

I've been long considering this. However it is just so tempting to cache the build results to boost future editing performance. Using a Expando should theoretically be equivalent. However the cost of Expando is poorly documented by DartVM (if not terrible by some of my past microbenchmarks) and so is the cost of a manual dynamic dispatching. These are extreme premature optimizations I must say, but I prefer to wait until editing feature is completed and have a side-by-side comparison.

Maintanence

Your suggestions are valuable. I don't have much experience on this matter. But I prefer to say that after feature-complete (i.e. editing) since a lot of stuff could be broken.

modulovalue commented 3 years ago

As a natural logic, it is best to split it into AST, TeX parser, TeX encoder, UnicodeMath parser, etc. However, each widget variant still needs a particular combination of these packages. Will they creat more-than-necessary amount of packages? Any good thoughts?

I think 2 packages would give the most value in terms of practicality and long term maintainability. I'm mostly just concerned about the flutter dependency since you have no control over flutter. You have full control over the rest, and as long as there are no platform dependencies, i believe one package should be fine for the dart-only part.

but I prefer to wait until editing feature is completed and have a side-by-side comparison.

That's a fair point. Editing has definitely a higher priority and the suggested changes can wait.

-- cc: @Sese-Schneider & @IchordeDionysos