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
Typo crashes the application on an iPad whenever you use Typo.js to get suggestions. It sometimes works the first time, but iOS will close the application if you spike memory usage - such as loading the dictionary and doing suggestion searches. I think this really needs to be optimized.
As a temporary work-around, I went through the entire .dic file and removed all of the words that my application doesn't care about, getting the .dic file down to 37k.
For example, if you know that a word has no rules, then dictionaryTable does not need to contain so many empty arrays, or arrays that contain empty arrays. These objects take up memory. Just null everything out. The biggest culprits seem to be the generated words based on the rules in the dictionaryTable. This one modification alone would dramatically reduce memory footprint.
Also, the API needs to be changed so that it's asynchronous and uses promises by default. For the longest time, I had no idea it could be asynchronous and so it was blocking the UI. Upgrading to promises though is just going to be more and more mandatory for libraries. Modern apps in Angular or whatever are all promise-based now, as is most browser databases. So it's actually a bit awkward to see a defaulted synchronous library. I think at this point in time, the people who want to be synchronous should have to jump through hoops, instead of the other way around.
A nice function to have would be stems() that simply accepts a word and returns all of the replacement words for the rules associated with it. For example, if you pass in 'vibrate', it returns something like ["vibrations", "vibration", "vibrating", "vibrates", "vibrated"]. This is very useful for building full text searches. Since you already have the rules and the dictionary, why not make this function public? I see most of the code buried in _parseDIC, but it could be refactored out as a prototype method.
The text was updated successfully, but these errors were encountered:
egervari
changed the title
Two issues I deal with a lot on tablets
Two issues I deal with a lot on tablets + one requested addition
Apr 15, 2016
Typo crashes the application on an iPad whenever you use Typo.js to get suggestions. It sometimes works the first time, but iOS will close the application if you spike memory usage - such as loading the dictionary and doing suggestion searches. I think this really needs to be optimized.
As a temporary work-around, I went through the entire .dic file and removed all of the words that my application doesn't care about, getting the .dic file down to 37k.
For example, if you know that a word has no rules, then dictionaryTable does not need to contain so many empty arrays, or arrays that contain empty arrays. These objects take up memory. Just null everything out. The biggest culprits seem to be the generated words based on the rules in the dictionaryTable. This one modification alone would dramatically reduce memory footprint.
Also, the API needs to be changed so that it's asynchronous and uses promises by default. For the longest time, I had no idea it could be asynchronous and so it was blocking the UI. Upgrading to promises though is just going to be more and more mandatory for libraries. Modern apps in Angular or whatever are all promise-based now, as is most browser databases. So it's actually a bit awkward to see a defaulted synchronous library. I think at this point in time, the people who want to be synchronous should have to jump through hoops, instead of the other way around.
A nice function to have would be stems() that simply accepts a word and returns all of the replacement words for the rules associated with it. For example, if you pass in 'vibrate', it returns something like ["vibrations", "vibration", "vibrating", "vibrates", "vibrated"]. This is very useful for building full text searches. Since you already have the rules and the dictionary, why not make this function public? I see most of the code buried in _parseDIC, but it could be refactored out as a prototype method.
The text was updated successfully, but these errors were encountered: