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
A bigger concern though: I am wondering if we're going to run into problems with the editor always being fully populated with large documents. I think we might be safer if we allowed people to edit a segment at a time (loading the next/previous in anticipation of shifts between segments). What do you think?
I think that it is not a bigger concern that thoughts about the fact we have alignment group creating process for all segments at once.
As for tokens editor what exactly do we have:
token inputs with watchers from the parent component - this way we have less watchers
we have only one menu component - that is re-assigned each time for each token - this way we have less components
I add tracking changes only on buttons click or options change (to reduce recalculating)
So this way I believe that I reduced the resources usage as much as I can.
And I certainly agree that both workflow - create aligned groups and update tokens , - would be much better to do inside one segment, while other segments are stored not in memory but in IndexedDB or remote source. And this way it would be more comfortable to use it with big texts.
I found some fixed discussions here in a closed issue - #2
But couldn't find requirements in issues for working by segments.
May be we should create such an issue and place it to some milestone:
we should define requirements for loading segments to both editers - for creating aligned groups and tokens edit
define where to store not uploaded segments and define in what format to store middle work for both editors
and define requirements how a user should switch between segments with the sight on how to reduce used resources
Anyway, it is a bigger task than is defined in the PR. @balmas , what do you think?
I think that it is not a bigger concern that thoughts about the fact we have alignment group creating process for all segments at once.
As for tokens editor what exactly do we have:
So this way I believe that I reduced the resources usage as much as I can.
And I certainly agree that both workflow - create aligned groups and update tokens , - would be much better to do inside one segment, while other segments are stored not in memory but in IndexedDB or remote source. And this way it would be more comfortable to use it with big texts.
I found some fixed discussions here in a closed issue - #2
But couldn't find requirements in issues for working by segments.
May be we should create such an issue and place it to some milestone:
Anyway, it is a bigger task than is defined in the PR.
@balmas , what do you think?
Originally posted by @irina060981 in #117 (comment)
The text was updated successfully, but these errors were encountered: