I want to use composable in vuejs3 to group some vuelidate logic but I'm encountering a problem with rules update when I want to validate dates
Here is a github repro, it will be much more easier to explain the problem with it
https://github.com/lou-theo/bug-vuelidate-composable-dates
In this example I have an input to set a dynamic threshold and then another input using this threshold for a min value rule
As we can see, this is working perfectly well with numbers but with dates, the threshold stay on the first value entered by the user
I guess I'm missing the understanding of some deep reactivity rules but I haven't found where the problem lies, that's why I'm asking for help
Related
I'am actually working on the calculation spreadsheet (Cartridge dev_basketinfo, pipeline InspectBasket-Start).
It works well but when I got a specific shipping mode (on weightbased and specific postalcode) it is empty.
Do you know something about it please ?
Thanks
The problem was a method called on the fly which invalidate the basket.
If you see an empty spreadsheet be careful with the invalidation or the ruleset.
I am starting a customer lifetime project at work and want to share how the data looks with the business, as I want to be able to identify the important variables with them. I plan to do this using the excellent rpivottable package and launch a shiny app to see where there are basic differences in groups to select my features.
This would mean I have my customer base of 4million customers and slice and dice them in a number of ways.
However, following GDPR we need to ensure no group is shown that has less than 7 customers in it. Therefore I need somekind of background calculation to ensure that less than 7 customers are never shown.
If I think logically about this, the only way I could see it working would be to make a change to the pivottable, have some form of submit button, so that the size of groups could be calculated, and then a filter (which needs to be hidden from the user so it cannot be switched off) is applied.
I know I should provide code, but I do not know where to start here. Has anyone had similar issues and has a potential solution to all or part of the problem?
Has anyone built a hidden filter into their rpivottable?
Has anyone been able to restrict their output to only show 90% of their data?
Thanks,
J
To be absolutely sure, you would need to load in a data frame that looks like "dim, dim, dim, count" where count is always greater than 7. Basically just a bit of preprocessing on your input data. Unfortunately, this means that you will be restricted to a small number of coarse dimensions, else you will end up filtering out everything.
First let's understand the app:
The sample app mocks grabbing data from 2 sources: an array of available objects, and an array of objects being used.
The app also displays new objects (available ones not being used).
Finally, it also allows you to use (register) one of the new objects
Requirements:
The app needs to display the list of New objects first
The app needs to minimize the number of API calls to the bare minimum and only make calls when strictly necessary
Calls to produce changes in API data (register) should be reactive and display changes in UI immediately
The code I have implemented meets these 3 requirements. However, I'm really unhappy with this implementation, and I'm sure that's not the way the Vuex store is supposed to be used.
For starters, my implementation only works for the specific order in which the components are displayed in the screen:
<new name="New" :selected="true"></new>
<available name="Available"></available>
<using name="Using"></using>
If I, for example, want to move <available> to the last tab, the code will break.
This happens because I haven't been able to simply call dispatch('getNews') once and have everything else fall into place, without at the same time duplicating one or to API calls, and thus not meeting the requirements...
I tried using dispatch('...').then().then() but I haven't been able to make it work and meet the requirements.
I would greatly appreciate anyone with experience in similar situations with Vuex tell me how they'd do this.
Bonus if you can do it without adding extra mutations.
Two questions: first, is it true that the only way to update '.priority' via REST is by using PUT, which forces you to rewrite all the other values? And I'm afraid to ask, but does that also apply to the Javascript SDK?
Second, is there maybe some other way other than using Priorities to order your collection 'server-side'?
Sorting things on the client doesn't work for me because I'm using a masonry-type plugin for layout which goes bonkers whenever the order changes client-side, but it seems to work fine server side. I'm using PHP to degrade the '.priority' value over time, lowering the item's position in the collection, but I'm forced to rewrite every other field at cron run. It works, but it would be better to just be able to update '.priority' or some other value that controls the position.
Question 1: .priority via REST API
You can set the priority without modify the record by calling PUT on the .priority directly. These examples are found in the REST API doc:
So, to reiterate, add .priority into the URL.
Question 2: Hacking masonry sorting in Angular using the data store?
If you haven't explored your options here, there are several libs dedicated to integrating masonry and angular which you may want to check out (e.g. angular-masonry). You may also have luck address sorting data in masonry directly, in its own SO question, rather than trying to solve it with your data store, which seems like an XY Problem.
The records in Firebase are sorted lexicographically, so you have three options:
name your items so they sort in the desired order
use push ids, which are ordered chronologically
use priorities to enforce a sort order other than the record id's natural sorting
Keep in mind that numeric keys, when mixed with lexicographic strings, cause behave strangely--err, by design--in Chrome. And, tangentially related, such a debate has waged that the ECMAScript standard will actually be changed to force them to correct it
I'm having a bit of a time trying to get Dojo grids (1.5) to play nice. Specifically I've spent about two weeks of work trying to implement a grid that allows for our result set data to collapse into rows, where rows can be expanded. Data comes in as a full set in JSON format, using ItemFileReadStore as the store. Any subsequent sorts or pagings are handled by GETing a new json from the application, and passing in new query parameters in the url.
The nested data was only two layers deep - a top layer to always be displayed and an array of child data with identical structure as the top layer. Each node has a unique ID and a cluster ID - on a parent node the unique ID and cluster ID will match.
I was initially very excited with TreeGrid - but I couldn't see how I could format it to do what I needed - namely eliminate the 'summary row' and one extra row full of null cells (???) that I just couldnt figure out how to remove unless I focused the query to only one cluster. I studied the test examples, built many test pages myself, tried to understand the forestModel, which for what I could tell was unnecessary... I found so little documentation, and sources I found online hinted that TreeGrid might not be reliable...
So I decided I would try to implement the expandable/collapsible rows in dataGrid.
I flattened the JSON data and added another attribute to indicate being a top level node ('alwaysShow' = true). I built my grid programaticaly and applied grid.filter() to pull only those top level nodes. I modified that filter by extending the ItemFileReadStore _FetchItems "filter" method to allow for OR querying instead of AND, and also modified it to allow for keys to point to arrays - when a top level node (small +/- icon in the cell) is clicked, the cluster ID of the parent node is added to the grid.filter.allowed[] and the filter is updated, allowing nodes with that cluster_id value to be displayed.
This worked fine on my small test set of five records (although id say a little slugish...) - but now I am pulling ~900 rows back from the application, and on expanding large clusters (~80 rows) I am seeing a very long flash of blue and white on the filter updates. I've spent most of my day trying to step through in firebug to find where its happening, but the dojo logic is so spread out. Seems to be happening before the call to _Grid.js defaultUpdate.
Its so bad that I am considering trying again with TreeGrid. Im also considering just doing this by hand... Im kicking myself for spending so much time trying to get Dojo to work to begin with. I would also consider a commercial "JSON->table with collapsible row" library if anyone has any recommendations...
Any suggestions or insights? Familiarity with the flashing problem or how I could adapt TreeGrid to my needs? I'm aware this is a bit of a rant... Many thanks for any help.
-robbie
EDIT: I eventually gave up trying to get Dojo to do what I needed and coded it myself in less than a day. Not the best use of three weeks...
EDIT:
I just found a solution that works for me, I have added the following CSS:
.dojoxGridSummaryRow {
visibility: collapse
}
Basically the summaries are probably still created but they are not visible nor taken into account in the table layout. That's good for me. Hope this will solve your issue.
This won't help but just to let you know that:
"- but I couldn't see how I could format it to do what I needed - namely eliminate the 'summary row' "
is the very EXACT same thing I'm trying to achieve and did not find the solution even though this looks like a very simple feature... Will let you know if I found a solution...