The DEFAULT is just the aggregation of the default list. Maybe add a defaultHeaders(Boolean|Array) option to allow users to enable or disable or override this implicit default request header instead of this DEFAULT. Some scenes:

default list contains: authorization, accept, content-type req.headers contains: authorization, accept, content-type, cookie, x-csrf-token, host, referer

{
  "name": "kras",
  ...
  "injectors": {
    "proxy": {
      "active": true,
      "defaultHeaders": true,
      "permitHeaders": ["cookie", "x-csrf-token"]
    }
  },
  ...
}

Finally allow Headers: authorization, accept, content-type, cookie, x-csrf-token 2.

{
  "name": "kras",
  ...
  "injectors": {
    "proxy": {
      "active": true,
      "defaultHeaders": false,
      "discardHeaders": ["host", "referer"]
    }
  },
  ...
}

Finally allow Headers: authorization, accept, content-type, cookie, x-csrf-token 3. And so on...

It may be that I made it complicated, anyway, your plan can already meet the current needs!

• If permitHeaders and discardHeaders are configured at the same time, discardHeaders is excluded based on permitHeaders, such as:

{
  "name": "kras",
  ...
  "injectors": {
    "proxy": {
      "active": true,
      "permitHeaders": ["DEFAULT", "cookie"],
      "discardHeaders": ["authorization"]
    }
  },
  ...
}

The DEFAULT element in permitHeaders is equivalent to default list.

• else discardHeaders is excluded based on headers of the request object, such as:

{
  "name": "kras",
  ...
  "injectors": {
    "proxy": {
      "active": true,
      "discardHeaders": ["authorization"]
    }
  },
  ...
}

The permit list is sufficient for most scenarios. Users can decide whether to allow or deny certain request headers. I'm not sure if these new request headers are safe, or perhaps remain the same until a new request is made by the user.

Very good suggestion, how to add the following two configurations to the proxy-injector: .krasrc

{
  "name": "kras",
  ...
  "injectors": {
    "proxy": {
      "active": true,
      "followRedirect": false,
      "permitHeaders": ["cookie", "x-csrf-token"]
    }
  },
  ...
}

1. proxy discards cookies and custom headers such as csrf token.
2. When the authentication expires, the json content-type is requested but the html content-type of 200 status is returned. If the followRedirect option can be set by the user, then the 302 status can be returned to the browser for processing. That's the patch

New Pull Request

For more information, see the CONTRIBUTING guide.

Prerequisites

Please make sure you can check the following boxes:

• [x] I have read the CONTRIBUTING document
• [ ] My code follows the code style of this project
• [ ] All new and existing tests passed

Type(s) of Changes

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [x] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• [ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] I have updated the documentation accordingly
• [ ] I have added tests to cover my changes

Description

[Place a meaningful description here]

Remarks

[Optionally place any follow-up comments, remarks, observations, or notes here for future reference]

Clean up the commit, pull a new PR.

Support https

New Pull Request

For more information, see the CONTRIBUTING guide.

Prerequisites

Please make sure you can check the following boxes:

• [ ] I have read the CONTRIBUTING document
• [ ] My code follows the code style of this project
• [ ] All new and existing tests passed

Type(s) of Changes

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• [ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] I have updated the documentation accordingly
• [ ] I have added tests to cover my changes

Description

[Place a meaningful description here]

Remarks

[Optionally place any follow-up comments, remarks, observations, or notes here for future reference]

ok

Thanks for pointing right

Thanks for pointing right

New Pull Request

For more information, see the CONTRIBUTING guide.

Prerequisites

Please make sure you can check the following boxes:

• [ ] I have read the CONTRIBUTING document
• [ ] My code follows the code style of this project
• [ ] All new and existing tests passed

Type(s) of Changes

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• [ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] I have updated the documentation accordingly
• [ ] I have added tests to cover my changes

Description

[Place a meaningful description here]

Remarks

[Optionally place any follow-up comments, remarks, observations, or notes here for future reference]

Hi, here is the background

Dependency names like "@scope/redux-saga/effects" are not valid

New Pull Request

For more information, see the CONTRIBUTING guide.

Prerequisites

Please make sure you can check the following boxes:

• [ ] I have read the CONTRIBUTING document
• [ ] My code follows the code style of this project
• [ ] All new and existing tests passed

Type(s) of Changes

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• [ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] I have updated the documentation accordingly
• [ ] I have added tests to cover my changes

Description

[Place a meaningful description here]

Remarks

[Optionally place any follow-up comments, remarks, observations, or notes here for future reference]

What I meant was that the swagger-injector plugin for kras never finished as I did not see anyone using this feature instead of more explicit mocks.

Understood!

Happy to continue there, or do you want to contribute?

I'm very sorry for this. I am not good at the development of back-end tools and have no experience in back-end development.

Swagger injector never finished - I started it but did not see much use unless someone wants it / finds it useful.

Yep, it seems that there are few projects using swagger. If the backend development uses swagger, this is very useful for front-end developers (used to monitor the response content field changes and export swagger files can be used to mock data).

Maybe,

1. Using a mustache string format in the response content of json-injector, like {{image.imageUrl}}

During use, it was found that the response content only supports string and buffer types, and support for the json type is more convenient for modifying complex response content.

2. Built-in faker.js in script-injector.
3. Added faker type in swagger-injector, like the x-faker of prism

By the way, is there any documents about swagger-injector？

The experience of using kras is very good, you can quickly switch between mock and proxy, if it can support the use of faker in the injector, it will be more perfect, like the x-faker of prism :100:

Bug Report

For more information, see the CONTRIBUTING guide.

Prerequisites

• [ ] Can you reproduce the problem in a MWE?
• [ ] Are you running the latest version?
• [x] Did you perform a search in the issues?

Environment Details and Version

piral-cli@0.11.5 IE11 piral-cli-webpack@0.5.3

Description

The page refresh is always triggered by webpack-dev-server. Under IE11, const ws = new WebSocket(updateTarget); will trigger a read ECONNRESET error after the page is automatically refreshed.

Steps to Reproduce

1. Debug pilet in ie11
2. Manually refresh the ie browser or modify the code to trigger the page to automatically refresh
3. webpack-dev-server crashed and output an error in the console:

Unhandled 'error' event
Error: read ECONNRESET

4. Works well on chrome browser

Expected behavior

[What you expected to happen]

Actual behavior

[What actually happened]

Possible Origin / Solution

If comment out this socket code, it works well on ie11. When I replace WebSocket with sockjs-client to be compatible with IE11(the code), it works fine on chrome and ie11. Is this feasible?

Work fine with kras under ie11! perfect!

The information you provided is very helpful. I also verified that piral is working well as expected, and continue to pay attention to the new features of piral, thank you!

Got it, you are the most responsive developer I have ever seen, and thank you for your patience and precious time for such a detailed answer. Thanks again!

I'm sorry I didn't re-view the new version of the document and only saw the discussion:

By default, this flag would pick the first integrated bundler (or install / try to choose Parcel or the bundler from the .piralrc file), however, it could be also just picked --bundler webpack: If not installed a plugin with that name will be resolved (piral-cli-webpack). Misunderstanding that all commands are compiled using webpack in the same way. So, following your instructions, re-use the 0.11.7-pre.1433 version, and found that the third-party (e.g., redux) shared dependencies are not excluded, and are included in the bundle package of the shell application and the pilet application: app-shell package.json

{
  "name": "app-shell",
  "dependencies": {
    "redux": "latest"
  },
  "pilets": {
    "externals": [
      "redux"
    ]
  }
}

pilet package.json

{
  "name": "sample-pilet",
  "dependencies": {
    "redux": "latest"
  },
  "piral": {
    "comment": "Keep this section to use the Piral CLI.",
    "name": "app-shell"
  }
}

Search for the redux code snippet in the browser, that still included in the bundle package of the shell application and the pilet application. Screenshot: Here is the sample

I updated to piral-cli@0.11.7-pre.1433, then used pilet debug --bundler webpack, and then showed ʻUnrecognized option: bundler`

In debug pilet mode, seems the shared dependencies did not work, and found that this code always didn't execute.

Can I test with the latest version now? If it is now, I will reproduce the issue that appears to you. If this function is still being tested, please ignore this message, thanks!

• the shared dependencies

Does this include scanning for dependencies that are not explicitly shared between the app shell and the pilet (including third-party dependencies)? The current idea is to use webpack-bundle-analyzer to scan the app-shell to get the results, visually check the relatively large dependencies and then summarize them in pilets.externals.

Do you mean this problem does not exist after switching to kras middleware?

Perhaps, temporarily block out the socket in the Internet Explorer browser to ensure that it does not crash under Internet Explorer?

I raised the issue here #21. :smile_cat:

Bug Report

For more information, see the CONTRIBUTING guide.

Prerequisites

• [ ] Can you reproduce the problem in a MWE?
• [ ] Are you running the latest version?
• [x] Did you perform a search in the issues?

Environment Details and Version

piral-cli@0.11.5 IE11 piral-cli-webpack@0.5.3

Description

The page refresh is always triggered by webpack-dev-server. Under IE11, const ws = new WebSocket(updateTarget); will trigger a read ECONNRESET error after the page is automatically refreshed.

Steps to Reproduce

1. Debug pilet in ie11
2. Manually refresh the ie browser or modify the code to trigger the page to automatically refresh
3. webpack-dev-server crashed and output an error in the console:

Unhandled 'error' event
Error: read ECONNRESET

4. Works well on chrome browser

Expected behavior

[What you expected to happen]

Actual behavior

[What actually happened]

Possible Origin / Solution

If comment out this socket code, it works well on ie11. When I replace WebSocket with sockjs-client to be compatible with IE11(the code), it works fine on chrome and ie11. Is this feasible?

Bug Report

For more information, see the CONTRIBUTING guide.

Prerequisites

• [ ] Can you reproduce the problem in a MWE?
• [ ] Are you running the latest version?
• [ ] Did you perform a search in the issues?

Environment Details and Version

piral-cli@0.11.5 IE11 piral-cli-webpack@0.5.3

Description

The page refresh is always triggered by webpack-dev-server. Under IE11, const ws = new WebSocket(updateTarget); will trigger a read ECONNRESET error after the page is automatically refreshed.

Steps to Reproduce

1. Debug pilet in ie11
2. Manually refresh the ie browser or modify the code to trigger the page to automatically refresh
3. webpack-dev-server crashed and output an error in the console:

Unhandled 'error' event
Error: read ECONNRESET
```

## Expected behavior

[What you expected to happen]

## Actual behavior

[What actually happened]

## Possible Origin / Solution

[Optionally, share your idea to fix the issue]

Yeah I thought about it for a bit - I think the best approach would not be a new template, but rather having support for variables in the template. Then there could be a variable like ie11 (or in general - "legacy browser support"), which would add a lot of that stuff we've seen in the PRs.

It would be opt-in and come only when you want that support.

Is a good choice.

(Still no version / CHANGELOG has been updated, so this will fail publishing ...)

After updating change.log, it still fail publishing...

Added default configuration for browserslist

New Pull Request

For more information, see the CONTRIBUTING guide.

Prerequisites

Please make sure you can check the following boxes:

• [ ] I have read the CONTRIBUTING document
• [ ] My code follows the code style of this project
• [ ] All new and existing tests passed

Type(s) of Changes

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• [ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] I have updated the documentation accordingly
• [ ] I have added tests to cover my changes

Description

[Place a meaningful description here]

Remarks

Support IE11

understood :smiley: At present, the logic of the piral-cli template is not very clear, and a set of templates will be output when the follow-up work progresses here, thank you.

Support IE11 configuration

New Pull Request

For more information, see the CONTRIBUTING guide.

Prerequisites

Please make sure you can check the following boxes:

• [ ] I have read the CONTRIBUTING document
• [ ] My code follows the code style of this project
• [ ] All new and existing tests passed

Type(s) of Changes

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• [ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] I have updated the documentation accordingly
• [ ] I have added tests to cover my changes

Description

[Place a meaningful description here]

Remarks

Support IE11

understood :smiley:

Support IE11 configuration

New Pull Request

For more information, see the CONTRIBUTING guide.

Prerequisites

Please make sure you can check the following boxes:

• [ ] I have read the CONTRIBUTING document
• [ ] My code follows the code style of this project
• [ ] All new and existing tests passed

Type(s) of Changes

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• [ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] I have updated the documentation accordingly
• [ ] I have added tests to cover my changes

Description

[Place a meaningful description here]

Remarks

Support IE11

understand :smiley:

Added default configuration for browserslist

New Pull Request

For more information, see the CONTRIBUTING guide.

Prerequisites

Please make sure you can check the following boxes:

• [ ] I have read the CONTRIBUTING document
• [ ] My code follows the code style of this project
• [ ] All new and existing tests passed

Type(s) of Changes

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• [ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] I have updated the documentation accordingly
• [ ] I have added tests to cover my changes

Description

[Place a meaningful description here]

Remarks

Support IE11

Support IE11 configuration

New Pull Request

For more information, see the CONTRIBUTING guide.

Prerequisites

Please make sure you can check the following boxes:

• [ ] I have read the CONTRIBUTING document
• [ ] My code follows the code style of this project
• [ ] All new and existing tests passed

Type(s) of Changes

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• [ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] I have updated the documentation accordingly
• [ ] I have added tests to cover my changes

Description

[Place a meaningful description here]

Remarks

Support IE11

Support IE11 configuration

New Pull Request

For more information, see the CONTRIBUTING guide.

Prerequisites

Please make sure you can check the following boxes:

• [ ] I have read the CONTRIBUTING document
• [ ] My code follows the code style of this project
• [ ] All new and existing tests passed

Type(s) of Changes

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• [ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] I have updated the documentation accordingly
• [ ] I have added tests to cover my changes

Description

[Place a meaningful description here]

Remarks

Support IE11

The problem has been resolved and verified

Aha, you may be right, I mistaken the tsconfig.json in the piral-cli-webpack directory for the tsconfig.json in the shell application directory, and I will return after verifying that there is no problem submitted.

my mistake.

You are right, moving the configuration to the package.json of the shell application is a more flexible and free configuration method. I strongly agree to remove the support of ie <11 and there are still some users who have a demand for ie11.

Do you mean to remove @babel/preset-typescript? I haven't figured out why the ts-loader did not convert the arrow function of the component.

Isolate the impact of the shell application on the global native objects of the pilet and reduce the bundle size of the shell application. Use useBuiltIns to support IE11.

Remove protocol and host for automatic adaptation. Works fine on chrome of mac notebook.

It seems to be because of the asynchronous problem. Is it adjusted to the following to fix this problem?

Here is just an example, you may have a better solution, in the logic of controlling the loading of the pilet.

The error page transition screen has been fixed. Awesome ！🎉 At the same time, through your explanation, I have a deeper understanding of the loading logic, thank you!

On the webpack branch, something went wrong:

OK👌

Tried to use the latest version piral-cli@0.11.6-pre.1324, but an error occurred while building the app-shell:

It seems to be because of the asynchronous problem. Is it adjusted to the following to fix this problem?

It seems that the schema-utils package officially released a compatibility issue caused by the new version

Bug Report

For more information, see the CONTRIBUTING guide.

Prerequisites

• [ ] Can you reproduce the problem in a MWE?
• [x] Are you running the latest version?
• [ ] Did you perform a search in the issues?

Environment Details and Version

piral-cli@0.11.5

Description

The piral-i18n plugin updates the language state and emits an event to notify another piral-antd to update the provider, but the provider rendered by the app-shell is still the old value.

Steps to Reproduce

1. piral-i18n

export function getLanguage(ctx: any){
 return ctx.readState((state: any) => state.i18n.language);
}
export function changeLanguage(ctx: any, language: string) {
  ctx.dispatch((state: any) => {
    ctx.emit('change-language', {
      current: language,
      previous: state.i18n.language,
    }
    return {
      ...state,
      i18n: {
       language: language,
      }
    }
  })
}

2. piral-antd

import { LocaleProvider } from 'antd';
const EnProviderLocale = require('antd/lib/locale-provider/en_US');
const OtherProviderLocale = ...
const language = context.getLanguage();
const LocaleProvider = createElement(
context.includeProvider(createElement(LocaleProvider, { locale: language === 'en' ? EnProviderLocale : OtherProviderLocale }));
context.saveOriginProvider(LocaleProvider, { locale: language === 'en' ? EnProviderLocale : OtherProviderLocale });

context.on('change-language', ({current, previous}) => {
  context.updateOriginProvider(LocaleProvider, { locale: current === 'en' ? EnProviderLocale : OtherProviderLocale });
});

actions.ts

function reIncludeProvider(providers, propses, index): any {
  const provider = providers[index];
  const prop = propses[index];
  const providerComponent = createElement(provider, prop);
  if(index > 0){
   return props => createElement(reIncludeProvider(providers, propses, index - 1), undefined, cloneElement(providerComponent, props));
  }else{
    return props => cloneElement(providerComponent, props);
  }
}

export function updateOriginProvider(ctx: any, provider: any, props: any){
  const originProvider = ctx.readState((state: any) => state.originProvider) || [];
  const providerProps = ctx.readState((state: any) => state.providerProps) || [];
  let providers = ctx.readState((state: any) => state.provider) || React.Fragment;
  const providerIndex = originProvider.indexOf(provider);
  if(providerIndex){
    providerProps.splice(providerIndex, 1, props);
    provider = reIncludeProvider(originProvider, providerProps, originProvider.length - 1);
    ctx.dispatch((state: any) => {
      return {
        ...state,
        providerProps,
        provider: providers,
      }
    })
  }
}
export function saveOriginProvider(ctx: any, provider: any, props: any) {
  ctx.dispatch((state: any) => {
    return {
      ...state,
        providerProps: [...(state.providerProps || []), props],
        originProvider: [...(state.originProvider || []), provider],
    }
  }
}

Expected behavior

When I switch languages, the provider will update.

Actual behavior

When I switch languages, debugging finds that the provider is still the old value.

Possible Origin / Solution

It was located because after the change-language was emitted, the latest provider was updated, and then the language was updated. At this time, the old value was re-acquired, so after adding setTimeout to emit, it worked as expected.

export function changeLanguage(ctx: any, language: string) {
  ctx.dispatch((state: any) => {
    setTimeout(() => {
      ctx.emit('change-language', {
        current: language,
        previous: state.i18n.language,
      }
    }, 100);
    return {
      ...state,
      i18n: {
       language: language,
      }
    }
  })
}

Although the dispatch was executed to update the state in the expected order, it also caused the page to be rendered twice. Is there a better way?

Please ignore it, it has been solved.

export function changeLanguage(ctx: any, language: string) {
  ctx.dispatch((state: any) => {
    return {
      ...state,
      i18n: {
       language: language,
      }
    }
  })
  ctx.emit('change-language', {
    current: language,
    previous: ctx.getLanguage(),
  }
}

Please ignore it, it has been solved.

I implemented an updated provider props, but encountered another problem. Use Pub / Sub to dispatch to update the state and get the old value

Bug Report

For more information, see the CONTRIBUTING guide.

Prerequisites

• [ ] Can you reproduce the problem in a MWE?
• [ ] Are you running the latest version?
• [ ] Did you perform a search in the issues?

Environment Details and Version

piral-cli@0.11.5

Description

The piral-i18n plugin updates the language state and emits an event to notify another piral-antd to update the provider, but the provider rendered by the app-shell is still the old value.

Steps to Reproduce

1. piral-i18n

export function getLanguage(ctx: any){
 return ctx.readState((state: any) => state.i18n.language);
}
export function changeLanguage(ctx: any, language: string) {
  ctx.dispatch((state: any) => {
    ctx.emit('change-language', {
      current: language,
      previous: state.i18n.language,
    }
    return {
      ...state,
      i18n: {
       language: language,
      }
    }
  })
}

2. piral-antd

import { LocaleProvider } from 'antd';
const EnProviderLocale = require('antd/lib/locale-provider/en_US');
const OtherProviderLocale = ...
const language = context.getLanguage();
const LocaleProvider = createElement(
context.includeProvider(createElement(LocaleProvider, { locale: language === 'en' ? EnProviderLocale : OtherProviderLocale }));
context.saveOriginProvider(LocaleProvider, { locale: language === 'en' ? EnProviderLocale : OtherProviderLocale });

context.on('change-language', ({current, previous}) => {
  context.updateOriginProvider(LocaleProvider, { locale: current === 'en' ? EnProviderLocale : OtherProviderLocale });
});

actions.ts

function reIncludeProvider(providers, propses, index): any {
  const provider = providers[index];
  const prop = propses[index];
  const providerComponent = createElement(provider, prop);
  if(index > 0){
   return props => createElement(reIncludeProvider(providers, propses, index - 1), undefined, cloneElement(providerComponent, props));
  }else{
    return props => cloneElement(providerComponent, props);
  }
}

export function updateOriginProvider(ctx: any, provider: any, props: any){
  const originProvider = ctx.readState((state: any) => state.originProvider) || [];
  const providerProps = ctx.readState((state: any) => state.providerProps) || [];
  let providers = ctx.readState((state: any) => state.provider) || React.Fragment;
  const providerIndex = originProvider.indexOf(provider);
  if(providerIndex){
    providerProps.splice(providerIndex, 1, props);
    provider = reIncludeProvider(originProvider, providerProps, originProvider.length - 1);
    ctx.dispatch((state: any) => {
      return {
        ...state,
        providerProps,
        provider: providers,
      }
    })
  }
}
export function saveOriginProvider(ctx: any, provider: any, props: any) {
  ctx.dispatch((state: any) => {
    return {
      ...state,
        providerProps: [...(state.providerProps || []), props],
        originProvider: [...(state.originProvider || []), provider],
    }
  }
}

Expected behavior

When I switch languages, the provider will update.

Actual behavior

When I switch languages, debugging finds that the provider is still the old value.

Possible Origin / Solution

It was located because after the change-language was emitted, the latest provider was updated, and then the language was updated. At this time, the old value was re-acquired, so after adding setTimeout to emit, it worked as expected.

export function changeLanguage(ctx: any, language: string) {
  ctx.dispatch((state: any) => {
    setTimeout(() => {
      ctx.emit('change-language', {
        current: language,
        previous: state.i18n.language,
      }
    }, 100);
    return {
      ...state,
      i18n: {
       language: language,
      }
    }
  })
}

Although the dispatch was executed to update the state in the expected order, it also caused the page to be rendered twice. Is there a better way?

It works fine ! :+1:

Of course, it is an honor!

I use it in various scenarios: Before the page is rendered, request the common data that the page depends on and set it in the redux store for the page to use.

const TranslatePage = () => import('./translatepage').then(m => m.default);
const common = () => import('./common');
const prerequest = () =>
  fetch('/somedata').then(res => {
    return import('./setstore').then(m => m.default(res));
  });
...
  app.defineDependency('common', common);
  app.defineDependency('prerequest', prerequest);
  app.registerPage('/translate', app.fromLazy(TranslatePage, ['common', 'prerequest']));

./setstore.ts

export default res => {
  console.log(res);
};

piral-lazy is great after improvement !

Bug Report

For more information, see the CONTRIBUTING guide.

Prerequisites

• [ ] Can you reproduce the problem in a MWE?
• [x] Are you running the latest version?
• [ ] Did you perform a search in the issues?

Environment Details and Version

piral-cli@0.11.5 piral-cli-webpack@0.5.3 Chrome@latest

Description

update piral-cli@0.11.5 and use piral-lazy

import { PiletApi } from '<name-of-piral-instance>';

export function setup(piral: PiletApi) {
  const LazyPage = piral.fromLazy(() => import('./MyPage'));
  piral.registerPage('/sample', LazyPage);
}

Steps to Reproduce

1. [First Step]
2. [next step...]

Expected behavior

[What you expected to happen]

Actual behavior

[What actually happened]

Possible Origin / Solution

[Optionally, share your idea to fix the issue]

Great, It works fine !