We Keep Coding

Adding query data to url in Svelte

I'm working on a SPA with Svelte. I have svelte-spa-router module installed. Nowhere seems to be documentation or examples how to add some object to your url.
This is easy in Vue:
router.push({ path: 'pathName', query: { someattribute: 'mygreatvalue' }})
In Svelte however the "push" only seems to support "location".
I tried some vanilla function but it adds the data in the wrong place.
My url looks like so:
myniftyspa.com/#/thepage
and I want:
myniftyspa.com/#/thepage/?someattribute=mygreatvalue
or:
myniftyspa.com/#/thepage/someattribute/mygreatvalue
it needs to stay on the page without reloading because I just want to store some data in the url this way. In the end it's about storing some ingredients information nested in an object that is being picked up after a revisit.

You can use vanilla window.history to set the current url without reload. Like so:
// address bar shows www.domain.com
window.history.pushState(null, '', window.location + '?foo=bar')
// address bar shows www.domain.com?foo=bar

I figured something out as a "solution" that works for now. Maybe it's helping someone with the same issue.
the object you want to be stored:
const ingrParams = [
{
id: 308,
gr: 100
},
{
id: 7,
gr: 100
},
{
id: 233,
gr: 80
}
];
The snippet:
push("/ingredients-to-nutrients/" + encodeURIComponent(JSON.stringify(ingrParams)));
let p = JSON.parse(params.paramnameyousetinrouter);
(push is an import of the svelte-spa-router module)
note: you need to do an initial push at onMount or else this push will be seen as a page change.

How to access secrets in Javascript GitHub actions?

I am developing a reusable workflow using Javascript actions by following this tutorial. My action.yml looks like this.
name: "Test"
description: "Reusable workflow"
inputs:
input-one:
required: false
type: string
runs:
using: 'node16'
main: 'dist/index.js'
But my question is how to access the secrets in dist/index.js?. Please note that I don't want the user to supply the secret as input, I would like to store the secret in my reusable workflow repository and use it whenever it's needed.
I tried to change the action.yml with env(So that I can use node process.env API to get the secret) but it's failing with an error saying that Unexpected value 'env'.
name: "Test"
description: "Reusable workflow"
inputs:
input-one:
required: false
type: string
runs:
using: 'node16'
main: 'dist/index.js'
env:
DUMMY_VAL: ${{ secrets.MY_REPOSITORY_SECRET }}

I don't think that's possible. That would be somewhat a security vulnerability.
Examples clearly show that secrets have to be explicitly passed https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-inputs-and-secrets-in-a-reusable-workflow
You can experiment with default value for it but looks like it's not supported for workflows.
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets
It would look like this (probably won't work):
on:
workflow_call:
secrets:
access-token:
description: 'Your secret'
required: false
default: ${{ secrets.your-secret }}
If it doesn't work you can try suggesting it as a feature here: https://github.com/orgs/community/discussions/categories/actions-and-packages

On GitHub.com, navigate to the main page of the repository. Under your repository name, click Settings. In the "Security" section of the sidebar, select Secrets, then click Actions. Click New repository secret.
Credit: Google

Does botbuilder support Facebook Messenger's Button Template?

After reading this question, which is quite old now:
Does the Bot Framework support Facebook Messenger's Button Template? and viewing the list of available cards using Bot Framework.
Does botbuilder currently support Facebook Messenger's Button Template? I would like the solution to be channel-agnostic so no JSON would be required to manipulate in order to achieve this. I've tried using the hero card with no title and no image but the result is not aesthetically pleasant and the normal text stays in bold.
This is the code which renders de card:
const attachment = CardFactory.heroCard(
"",
"BotFramework Hero Card",
CardFactory.images([]),
CardFactory.actions([
{
type: "openUrl",
title: "Get started",
value: "https://learn.microsoft.com/en-us/azure/bot-service/"
},
{
type: "openUrl",
title: "Get started2",
value: "https://learn.microsoft.com/en-us/azure/bot-service/"
}
])
);
return MessageFactory.attachment(attachment);
Tried also with the ThumbnailCard but shows the same result...

If you send a hero card through the Facebook connector then it will automatically be converted to a button template if the card has only buttons and no text or images, and it will be converted to a generic template otherwise. If you want to send a customized template of your choice, you can use Bot Framework channel data. It might look something like this:
reply = {
'type': ActivityTypes.Message,
'channelData': {
'attachment': {
'type': 'template',
'payload': {
'template_type': 'button',
'text': 'Button Template',
'buttons': buttons
}
}
}
};
Note that while the answer to your question is yes, you may still be unsatisfied. You only asked for a way to use the button template instead of the generic template but your reasoning was that you want it to look better. The problem there is that the look will depend on which Messenger client you're using, and in some clients this button template will look no different from a generic template. If you try out the button template and you're still unsatisfied then you may have to do some experimenting. I think the fastest way to test this would be to send messages as your bot in an HTTP application like Postman using the Bot Framework REST API.

Algolia not accepting all settings

I have the following Algolia request:
index.setSettings({
getRankingInfo : 1,
attributesToIndex:"name,colour,style,material,category",
hitsPerPage: 50,
ignorePlurals : false,
attributesToRetrieve : "objectID",
restrictSearchableAttributes :
"name,colour,style,material,category",
typoTolerance: "strict",
queryType: "prefixNone",
page : skipParameter
});
index.search(query, function(error, content) {
....
})
However, some of the settings don't seem to be applied to the search. For instance, it retrieves all attributes and I'm pretty sure the searchable attributes aren't restricted. Furthermore, the ranking info isn't returned as can be seen by the returned JSON with the hits post-emptied which means it is definitely not accepting at least that setting.
{"hits":[],"nbHits":173,"page":0,"nbPages":4,"hitsPerPage":50,"processingTimeMS":3,
"query":"Red sofa","params":"query=Red%20sofa"}
I'm running this code in a Parse.com cloud code search method if that may have an effect on the outcome?

There is some syntax errors.
First attributesToIndex should be an array:
'attributesToIndex': ["name", "colour", "style", "material", "category"]
same for restrictSearchableAttributes
Also you can get a response from algolia when you set settings, so you would be able to see errors with the config. ex:
index.setSettings({
'customRanking': ['desc(followers)']
}, function(err, content) {
console.log(content);
});
Some helpful resources:
https://github.com/algolia/algoliasearch-client-js
https://www.algolia.com/doc/rest_api
https://www.algolia.com/doc/tutorials/parse-algolia
And be sure to use the latest version of Algolia JS client
https://github.com/algolia/algoliasearch-client-js/wiki/Migration-guide-from-2.x.x-to-3.x.x
Happy sunday coding! :)

Duplicated rows when sorting dgrid 0.3.6

I've been using dgrid 0.3.2 along with JsonRest to display tables of data. Recently, I've been looking at upgrading to dgrid 0.3.6 or 0.3.7. Things work mostly the same, but it seems with the newer versions of dgrid that, if the user clicks a column header to sort fast enough, the grid will start displaying duplicate rows. I’ve verified that the response JSON and range are correct, and this didn’t seem to happen when we used dgrid 0.3.2.
Here’s a simple test case that reproduces the problem, and mimics how we set up our grid and store. Am I doing something wrong? If I don’t wrap the JsonRest in a Cache, I don’t get this issue, so I’m sure the problem is there, but I’m unsure about the performance ramifications of not caching the JSON response.
<!doctype html>
<html>
<head>
<%
String dgridVer = request.getParameter("dgridVer");
if (dgridVer==null) { dgridVer = "0.3.6"; }
%>
<script type="text/javascript">
var dojoConfig = {
isDebug: true,
baseUrl: 'dojo',
packages: [
{ name: 'dojo', location: 'dojo' },
{ name: 'dijit', location: 'dijit' },
{ name: 'dojox', location: 'dojox' },
{ name: 'dgrid', location: 'dgrid-<%=dgridVer%>' },
{ name: 'put-selector', location: 'put-selector' },
{ name: 'xstyle', location: 'xstyle' },
{ name: 'datagrid', location: '../datagrid' }
]
};
</script>
<script src="dojo/dojo/dojo.js"></script>
</head>
<body>
Try sorting a column as fast as you can. Look for duplicated rows.<br>
Using dgrid version: <%=dgridVer %><p>
<div id='gridDiv'></div>
<script>
require(['dgrid/Grid', 'dgrid/extensions/Pagination', 'dojo/store/JsonRest',
'dojo/store/Cache', 'dojo/store/Memory', 'dojo/_base/declare', 'dojo/domReady!'],
function(Grid, Pagination, JsonRest,
Cache, Memory, declare) {
var columns = [
{ field: "first", label: "First Name" },
{ field: "last", label: "Last Name" },
{ field: "age", label: "Age" }
];
var store = new JsonRest({
target: 'testData.jsp',
sortParam: "sortBy"
});
store = Cache(store, Memory());
var grid = new (declare([Grid, Pagination]))({
columns: columns,
store: store,
loadingMessage: 'Loading...',
rowsPerPage: 4,
firstLastArrows: true
}, 'gridDiv');
});
</script>
</body>
</html>

Check the default implementation of Cache.js, especially the query and queryEngine functions. By default they always get first to the master store, which in your case is the JsonRest store. Only after the data has been loaded, the caching store is updated (in your case the Memory store).
Now, if you check function _setSort in DGrid List.js file, and function refresh in DGrid OnDemandList.js you'll sill see that by default DGrid calls the query method of the current store to obtain the new list of items sorted differently. In your case that store is the dojo/store/Cache.
So, summing up, when the user clicks the column to sort, DGrid queries the Cache, which in turn queries JsonRest, which in turns queries the server, which then returns new data, which then the Cache stores in the Memory store.
You can actually confirm this for example with Firebug (a Firefox extension). In my case whenever I tried to sort, Firebug was showing a new request to the server to obtain new data.
This makes sense when there are lots of rows because DGrid is designed to load only the first batch of rows and then update the grid when user scrolls down. When the sort is changing, the first visible batch of rows may be different and may not be loaded yet, so DGrid must load them first.
But in my case the Json request was returning all data during a single request. I didn't like the default implementation and implemented my own caching store which doesn't require a trip to the server when changing the sorting. I can't share the implementation now but will try to do when I have some time to tidy up the code.
As for now you shouldn't notice any performance problems if you switch to JsonRest store only (considering that when changing the sorting there is the trip to the server anyway).
I am not sure what causes the specific problem of duplicated rows, but I remember seeing it too when my caching store wasn't implemented properly (it had something to do with deferred requests when loading data If I recall correctly). You can try to debug it by adding (again with Firebug) breakpoints in the get and query functions of the Cache store. My bet is that DGrid tries to load particular rows with the get method (which hits the cache) while the query request is still loading data from the server after user changed the sorting. But I may be wrong so please try to confirm it first if you can.