Dan Shockley:
In my app, I have an action script for onAppLoad. I added a BF_SetAction_Path to the FM script that calls so that, if the current path (page) is “profile”, navigate to the “default” path instead.
(Basically, while we want to reload whatever page the user was on when they quit the app, that isn’t true for the profile page.)
So, in my FileMaker BF - onUtility - global script, I have this:
Set Variable [ $type ; Value: JSONGetElement ( $$BF_Hook ; "options.type" ) ]
If [ $type = "onAppLoad" ]
If [ JSONGetElement ( $$BF_Model ; "_activeNav" ) = "profile" ]
Set Variable [ $$BF_Actions ; Value: BF_SetAction_path ( "/default/" ; "" ) ]
End If
Perform Script [ Specified: From list ; "Load User into BF_App" ; Parameter: ]
End If
That works, but the (still-empty, since $$BF_App isn’t loaded yet) profile page briefly appears before the user is redirected to the “default” page.
Note that I do want the user to be able to get to the profile page, just not have its emptiness be the first thing they see when they open the app.
Is there any way to capture and redirect this sooner?
Eduardo Aramizu:
it might work better if you just have a function on your onAppLoad to check that, instead of running a utility hook for that. You can use the following in your function
window.location.hash
and that would give you the result, e.g.
'#/profile'
so your function would look like
let currentHash = window.location.hash;
if (currentHash.includes('profile') {
BF.namedAction('redirectUser', {path: '/default'})
}
And then you’d have the named action redirectUser with the following
{
"action" :"path",
"options" :
{
"path": "/"
}
}
Dan Shockley:
That’s great! I had been hoping to put all the logic in the onAppLoad action script, but hadn’t figured out how to do it.
The documentation for BF.namedAction(name, options) says this:
Runs a named action, options are propagated to all actions within the named action.
So, does that imply that the redirectUser named action could be simply:
{
"action" :"path"
}
…since I’m sending in the desired options as the 2nd param when I do BF.namedAction('redirectUser', {path: '/default'}) ?
Eduardo Aramizu:
options are required for that action, but you’re right, the key being passed to this named action will be used for this case
Dan Shockley:
So, you mean that the incoming {path: '/default'} means the redirectUser action will ignore its own internal "options" :{"path": "/"} , and use the incoming specification that the options.path should be “/default” instead of “/” ?
Eduardo Aramizu:
correct
Dan Shockley:
So, in my onAppLoad action script, I added a function action, with this:
{
"action": "function",
"function": "let currentHash = window.location.hash;\n\nif (currentHash.includes('profile') {\n BF.namedAction('redirectUser', {path: '/default'})\n}",
"options": {}
}
I created a redirectUser action script with this action:
{
"action": "path",
"options": {
"path": "/"
}
}
I disabled the BF_SetAction_path ( "/default/" ; "" ) inside the FileMaker script (which worked).
But, when I quit and relaunch the app, it now stays on the profile page.
Where’s the best place to view the logs so I can see why the action(s) failed to do a redirect?
Eduardo Aramizu:
you can add console logs to help you check what’s actually running.
So I’d add one on the function (where you’re checking the hash), and then on the named action as well, so your path would be something like
{
"action": "path",
"function": "console.log('redirectUser start')",
"options": {
"path": "/"
}
}
Dan Shockley:
I added console.log code in both actions. But, when I load the app in Safari with the Javascript Console showing, I don’t see the new messages.
I do see a bunch of errors from code that was in the PWA template that I don’t think I’m using, much of it relating to marker.io calls. Could those be getting in the way?
Eduardo Aramizu:
Depending on what the errors are, it could be stopping the actions processor, yes
Dan Shockley:
Hmm. So, I’d love to go in and remove more of the unused/configured code that came with the PWA template.
I’ve looked through the documentation, but haven’t found the answer to this question:
Is there some way in the IDE to search [the content of] all my pages/scripts/etc at one time?
If not, is there some way to download my app as JSON (or something) to my local Mac, so I can search things there? I’m thinking of the FMBF equivalent to Save a Copy as XML in FileMaker?
Eduardo Aramizu:
no, unfortunately we’re currently unable to do a global search on your app, nor export the entire app as JSON or any other data type
Dan Shockley:
oh. That’s too bad. Being able to search within a project is a very useful thing, and used a lot in most development environments.
Is there a chance search is a feature being considered?
Eduardo Aramizu:
yes, that feature is part of our Roadmap
Dan Shockley:
So, in regards to the marker.io code - is that something that is embedded in the FMBF code itself, or something within my app that i can remove?
If it is part of FMBF’s own platform code, do I need to configure marker.io to work with my app, as the console errors seem to indicate?
Eduardo Aramizu:
If you’re using the template “Mobile PWA”, you might have it added on your DOM Header Insertions - Load Later, so you can find the script tag there corresponding to marker.io and remove it
Dan Shockley:
That’s where it was - thank you. I hadn’t gotten to that particular spot yet.
Eduardo Aramizu:
No problem
Dan Shockley:
Out of curiosity, was there a reason you chose currentHash.includes('profile') instead of currentHash === '#/profile' ?
If not, here’s the function that ended up working for me (fixed a missing parenthesis, which the console helped find after all the miscellaneous old code errors weren’t cluttering up the console):
{
"action": "function",
"function": "let currentHash = window.location.hash;\n\nif ( currentHash === '#/profile') {\n BF.namedAction('redirectUser', {path: '/default'});\n}",
"options": {}
}
And, happily, once I moved that to the beginning of the onAppLoad action script (before my utility hook script call), when a PWA is quit from the Profile page, and then re-opened, the profile page flashes so briefly before the redirect happens that it is hard to notice.
Eduardo Aramizu:
Great that’s working. No, there’s no major difference there, includes is a bit more forgiven (could have things appended before or after ‘profile’), however, in this case, I don’t see any issues with you using this